#2563 large shift ops wrong

obsolete: 8.5a0
closed-fixed
5
2004-09-19
2003-12-31
No

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)

Discussion

  • Donal K. Fellows

    • milestone: --> obsolete: 8.5a0
    • labels: 105657 --> 47. Bytecode Compiler
    • summary: <> x (x>=bitcount of architecture) is wrong --> <</>> x (x>=bitcount of architecture) is wrong
    • assigned_to: dkf --> msofer
    • status: open --> pending-wont-fix
     
  • Donal K. Fellows

    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.

     
  • Gerhard Hintermayer

    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.

     
  • Gerhard Hintermayer

    • status: pending-wont-fix --> open-wont-fix
     
  • miguel sofer

    miguel sofer - 2004-01-08
    • assigned_to: msofer --> dkf
     
  • miguel sofer

    miguel sofer - 2004-01-08

    Logged In: YES
    user_id=148712

    assigning to knowledgeable developer ...

     
  • Donal K. Fellows

    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.

     
  • Nobody/Anonymous

    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

     
  • miguel sofer

    miguel sofer - 2004-01-12

    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 ;)

     
  • Donal K. Fellows

    • summary: <</>> x (x>=bitcount of architecture) is wrong --> large shift ops wrong
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902

    Fixed in HEAD.

     
  • Donal K. Fellows

    • status: open-wont-fix --> open-accepted
     
  • Donal K. Fellows

    • status: open-accepted --> closed-fixed
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902

    And in 8.4 branch too.

     
  • Don Porter

    Don Porter - 2004-09-18

    Logged In: YES
    user_id=80530

    patched HEAD fails the following tests
    on a 64-bit platform:

    ==== expr-24.5 expr edge cases; shifting FAILED
    ==== Contents of test case:
    expr int(5)<<32
    ---- Result was:
    21474836480
    ---- Result should have been (exact matching):
    0
    ==== expr-24.5 FAILED

    ==== expr-24.6 expr edge cases; shifting FAILED
    ==== Contents of test case:
    expr int(5)<<63
    ---- Result was:
    -9223372036854775808
    ---- Result should have been (exact matching):
    0
    ==== expr-24.6 FAILED

     
  • Don Porter

    Don Porter - 2004-09-18
    • status: closed-fixed --> open-remind
     
  • Donal K. Fellows

    • status: open-remind --> closed-fixed
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902

    OK, those tests are failing because I'm not very good at
    writing tests, and not because what they are testing is
    failing. Silenced.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks