[Tcl-bugs] [ tcl-Bugs-868467 ] large shift ops wrong

[SourceForge.net <no...@so...>]

Bugs item #868467, was opened at 2003-12-31 15:12
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=868467&group_id=10894

Category: 46. Bytecode Compiler
Group: obsolete: 8.5a0
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gerhard Hintermayer (hinteger)
Assigned to: Donal K. Fellows (dkf)
Summary: large shift ops wrong

Initial Comment:
expr does not deliver correct results for <</>>, if the
shift count is equal (or greater) the bitcount of an
integer.

e.g. expr 5>>32 gives 5, instead of expected 0
      expr 5>>33 gives 2, instead of expected 0

Ok, as someone said on clt, this isn't covered in C89
Standard too, but do we have to stick to faulty
standards, that were set up years ago.

For implementing shifts of bit fields wider than int,
this is required to work correctly (ok, I could do
conditional expr's, but the code gets quite ugly)

----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2004-09-18 20:25

Message:
Logged In: YES 
user_id=79902

And in 8.4 branch too.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2004-09-18 19:04

Message:
Logged In: YES 
user_id=79902

Fixed in HEAD.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2004-01-12 11:56

Message:
Logged In: YES 
user_id=148712

No, it means: when a patch is submitted, it'll get judged by
someone who's got a clue ;)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-01-12 11:38

Message:
Logged In: NO 

this is on linux x86 with gcc 3.2. I got responses on
c.l.t., that Standard C89 doesn't define this, so probably
any compiler will give us an incorrect result, but ther's no
reason to do a shift count check and return 0 in all cases
where the shift count is greater or equal bitcount of integer.
btw. means

>assigning to knowledgeable developer ...

there's no need for a patch anymore ?
I didn't have time to submit a patch, maybe I'll make it
this week I'll , but I can test only on Linux, I don't have
a Win* Environment !

Gerhard



----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2004-01-09 09:38

Message:
Logged In: YES 
user_id=79902

Which platform is this on BTW?  And which compiler was used?

I ask because a VC++ 5.2 compiler bug was found recently in
the handling of shifts of 64-bit values.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2004-01-08 23:02

Message:
Logged In: YES 
user_id=148712

assigning to knowledgeable developer ...

----------------------------------------------------------------------

Comment By: Gerhard Hintermayer (hinteger)
Date: 2004-01-07 22:17

Message:
Logged In: YES 
user_id=124720

Regardless who's to blame for that, the result is not
correct. I'll take a look at the code and send a patch.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2004-01-01 16:35

Message:
Logged In: YES 
user_id=79902

Tcl just fires the value off to the C runtime's standard
shifting mechanism, and always has done AFAICT.  We don't do
range checks on the shift parameter.  If it is wrong, it's a
compiler, runtime or processor fault.

Not closing outright as perhaps this is something we could
check for.  But I'm not inclined to do anything about it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=868467&group_id=10894