Re: playout garbled in iPhone 3.x Release build (solved)
Re: playout garbled in iPhone 3.x Release build (solved)
- Subject: Re: playout garbled in iPhone 3.x Release build (solved)
- From: Tim <email@hidden>
- Date: Sun, 02 May 2010 20:58:11 -0700
On May 2, 2010, at 4:53 PM, Kyle Sluder wrote:
On May 2, 2010, at 4:39 PM, Tim <email@hidden> wrote:
On Sun, May 2, 2010 at 3:56 PM, Tim <email@hidden> wrote:
What you suggested would add an unnecessary instruction unless the
compiler
was smart enough to remove it, which I think is what it did,
because I did
try replacing ( bits >= 0 ) with ( !(bits & 0x80000000 ) ) and it
did not
change the behavior, even though I could plainly see from print
statement
the bits satisfied both of those conditions. Somehow bits = bits +
bits; is
not setting the status register bits which the if( ) branch depends
on. Or,
the branch is incorrectly evaluating the overflow condition.
Probably
something to do with 64-bit support.
Your code relies on undefined behavior. See here for a description of
why your code breaks on GCC 4.1.2:
https://www.securecoding.cert.org/confluence/display/seccode/MSC15-
C.+Do+not+depend+on+undefined+behavior
They are talking about testing for overflow. I am not testing for
overflow. I am testing the result of an arithmetic operation. The
result is a positive number. The fact that it was previously a
negative number should have no bearing on the test. Here is what I
am doing in nutshell:
long x = 0x80000001;
x = x + x;
if( x >= 0 ) printf("no bug");
else printf("bug");
The compiler is free to optimize that statement to remove the branch,
because the result of the addition above is undefined since it causes
overflow. The compiler will have done dataflow analysis to resolve
that you added two positive integers together, so x >= 0 is a
tautology.
If you are saying the result of this is undefined, a lot of code is
broken.
Yes, I am, and yes, it is.
Sorry, you are right, I didn't read the link you posted close enough.
I guess it makes sense that signed integer overflow would be undefined.
All of the code I was thinking of that depends on integer overflow
occurring in a well defined way, e.g., time stamps, sequence numbers,
circular buffer indices, etc., should be using unsigned integers, and
that is what I always do. So, yes, this code is very peculiar for
using a signed integer to store some bits that don't even represent a
number.
However, from what I could gather at that site, the shift operator is
also considered an arithmetic operation? So the fact that using x <<=
1 fixes it was just good fortune. I think the better fix is:
unsigned long x; // make sure overflow behavior is well defined
x <<= 1; // let compiler convert to ADD if that is faster than shift
if( ((signed long)x) >= 0 ) { // test high bit
printf("hi bit is not set");
}
I know, you would recommend more direct use of bit field operators, but
the last time I looked at implementations, they were incredibly slow,
aimed at random access, not marching through a stream of bits
sequentially. And, then I may have a whole new family of bugs to
investigate due to the CPU not being able to keep up. So, yeah, don't
waste time on pre-mature optimization, but if it's already done and it
works, no reason to throw it out. I need to achieve real time
performance on mobile devices with relatively slow CPU's (some lower
end than iPhone), and every wasted CPU cycle is burning battery.
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden