#1 Integer overflow in flake.c, line 449 (for rev.108)

closed-fixed
nobody
None
5
2006-10-20
2006-10-14
Anonymous
No

For rev.108 I still have in output:

Signed 16-bit 44100 Hz stereo
samples: 116712120 (0m16.961s)

I think overflow has place in expression evaluation
stage, before assignment. So it's better ether cast int
to long for wf.samples or use long constant (1000L).

For me 1000L gives:

Signed 16-bit 44100 Hz stereo
samples: 116712120 (44m6.533s)

Can value of wf.samples be greater then range of
unsigned int type? I see you define it as uint32_t in
WavFile struct in wav.h. So then result of "uint32_t *
1000 / 44100" can't be greater then uint32_t and even
just int also :) So I think 'tms' var can safely be
int as before.

Discussion

  • Justin Ruggles

    Justin Ruggles - 2006-10-18

    Logged In: YES
    user_id=1394814

    The multiply is done first, so overflow can still occur. I
    think I have solved it by doing the math in floating-point
    then converting the result to integer.

     
  • Justin Ruggles

    Justin Ruggles - 2006-10-18
    • status: open --> open-fixed
     
  • Nobody/Anonymous

    Logged In: NO

    You are right, but 1000L WORKS for me because I compile
    program under 64bit system ;) I assume gcc under x86_64 uses
    long long for such constants.

    But it's possible to cast uint32_t wf.samples explicitly to
    uint64_t for this expression to get "usual arithmetic
    conversions" in action:

    tms = (uint64_t)wf.samples * 1000 / wf.sample_rate;

    I think it's better then use floating point arithmetics
    where it doesn't need.

     
  • Justin Ruggles

    Justin Ruggles - 2006-10-20
    • status: open-fixed --> closed-fixed
     

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

Sign up for the SourceForge newsletter:





No, thanks