[LCP]query regarding pointers in C

[David Spencer]

Sameer Oak wrote:

>>Why post nonsense when the correct answer has already been
>>posted to the list?
>>    
>>
>...
>i'm sure the answer i posted had no nonsense stuff in it.
>
>  
>
You posted an explanation of why that particular compiler produced the 
results, although you didn't distinguish between the implementation and 
the standard.  A beginner might believe that the use of multiple 
operators with side effects in the same statement has defined behaviour 
when it doesn't or, worse, that it is a good idea.

Your comments made sense to me, so I think "nonsense" is a bit on the 
harsh side.  I think that must be Greg's style - I'm in a charitable 
mood this morning so I'm sure he isn't really as anally retentive as 
some of his posts suggest.

>>and don't post answers until you know the truth.
>>    
>>
>...
>well...so what's the truth? can you kindly explain. you see am too novice to
>know the truth.
>
>  
>
The truth is that there is standard behaviour and nonstandard behaviour, 
and it is important in programming, which relies on accuracy, to 
distinguish between the two.

Another truth is that you learn by conversation.  That means posting BS 
on occasions and having it deconstructed.  Unfortunately some people 
seem to think that nobody should post answers unless their posts are 
100% correct.  More unfortunately, "correct" is usually defined by the 
person who objects to incorrect posts, so determining what they think is 
correct and what they think isn't by not posting can be difficult.  Last 
time I checked, this list was "linux c programming", not "Standard C 
programming" or "comp.lang.c" so I would have thought questions about 
actual, rather than standard, behaviour would have been ON topic.

>>In the meantime, repeat after me: the original program is
>>    
>>
>undefined and so there is no way of knowing what it "should"
>do.  Undefined means undefined.
>...
>undefined! what dya mean by undefined?
>
>  
>
www.dictionary.com gives a good definition.  Not defined (by the 
standard, although this is distinct from "not implemented by the 
compiler.")  In context, it means that any behaviour of a statement 
containing multiple side effect operators is not to be relied on when 
porting the code to a different compiler (including a different version 
of the same compiler on the same platform).  Also it means that 
questions on that statements behaviour cannot be answered by the 
standard, because the standard doesn't define that behaviour.  So as far 
as the standard is concerned, x=a++ + a++; may assign 2a to x; it might 
assign a+a+1 to x; it might reformat your hard drive; it might even make 
the tea if you have appropriate hardware.  It can be answered in the 
form of "this is how this particular compiler under these particular 
circumstances might treat this undefined sequence", but it can't be 
answered in terms fo the C programming Standard.

This is important because it can lengthen development and debugging 
time.  Suppose you type "x=a++ + a++;" on a platform where this 
statement behaves similarly to "x=2*a; a+=2;"  In order to be sure it 
still behaves this way on a different compiler, for example if you port 
the code to Windows, or if you upgrade gcc from 2.95 to 3.0, you will 
need to test the code (i.e. lengthen development time), or meet an 
extremely obscure bug (i.e. lengthen debugging time) should you be 
unfortunate enough to move the code to somewhere where the compiler 
evaluates the postincrement more immediately, resulting in "x=2*a+1; 
a+=2;" - because x is now 1 too large.

Dave.