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: Kyle Sluder <email@hidden>
- Date: Sun, 2 May 2010 16:53:57 -0700
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.
In the future, it would be to your benefit to retrain your brain to
not try to shortcut around the compiler. Write code that describes
your intent rather than an optimal implementation. Then profile and
optimize to the minimum level necessary.
This is good advice, but I don't think it makes sense to rewrite
working code to "unoptimize" it unless it is really doing peculiar
stuff. This is especially true with the kind of low level bit
twiddling code that is common in audio/video codecs and network
protocols.
Bit-twiddling code should use bit-twiddling operators, not undefined
side-effects of arithmetic operations. This is especially true in
today's world of cross-compiling on a 64-bit Intel machine to target a
32-bit Intel simulator for a 32-bit ARM device, using a language whose
behavior is defined by an abstact virtual machine.
--Kyle Sluder
_______________________________________________
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