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.
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.
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.
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.