On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
> Okay, fun C question of the month to see if Mike is paying attention. I'm
> getting a warning I've never seen in current svn:
Hey, cool. Some C Trivia in the morning to get me going. Let's see...
> BDSKTemplateDocument.m:1393: warning: operation on 'i' may be undefined
>
> keys = [keys subarrayWithRange:NSMakeRange(++i, [keys count] - i)];
This one is undefined because i is modified and read in the same expression.
Undefined is bad - the compiler could do anything and it would be
allowed, even writing random bytes to memory.
>
> Is this because the second argument may use the previous value of i?
Since the meaning is ambiguous, it's just disallowed in the standard
-> "undefined".
I'm not sure why it's not an error, honestly.
>A related question that bothers me whenever I see it:
>
> id obj;
> while (i < 10)
> obj = [array objectAtIndex:++i]; // and what about objectAtIndex:i++ ?
>
> If I understand correctly, all side effects take place before a function is
> called, so this should be safe...right? Af first glance, both situations
> seem similar to the example in K&R:
Yes, that second one is safe. The span of time when a variable
modification is in flux is between 'sequence points', and function
calls, just after evaluating their arguments, are a sequence point.
In the first example, ++i and i are not separated by a sequence point,
so all bets are off.
Interestingly, logical operators are also sequence points, so the
expression in this loop test:
while( (c = getchar()) && c!= EOF){}
is legit - the effects of the first half of the expression are
guaranteed to be completed before the second half.
>
> printf("%d %d\n", ++n, power(2, n)); /* WRONG */
>
> ++n;
> printf("%d %d\n", n, power(2,n));
>
> or
>
> a[i] = i++;
>
For these ones, there's a line in the standard that says that if an
object (variable) is written to within a full expression, all accesses
to it must be directly involved in the computation of the value to be
written.
The reason is that if that is true, we know we just always access the
previous value, and only modify it after all accesses.
That's not the case here, and there's no good rule for how to order
the accesses and the writes, so it's disallowed.
-mike
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
