From: tristan.wibberley+netnews2@alumni.manchester.ac.uk   
      
   On 14/01/2026 06:02, Keith Thompson wrote:   
   > Perhaps the exception Tristan was referring to (though it doesn't apply   
   > to indexing) is this, in N3220 6.5.10p7:   
      
   I think I was referring either to C++ or to an inference somebody else   
   had made once upon a time - or else the historical final-drafts   
   documents are different now than they were :/ Possibly K&R C specified   
   something more defined than ISO C, I have lent my book out so I can't   
   check. It was supposedly updated to ISO C. Possibly it was pre-K&R C or   
   implementation specific that I picked up as a teen and my uni professor   
   cemented it in my mind as correct C when he gave me 100% for an   
   assignment in which I used it - and he was a stickler regarding   
   undefined behaviour.   
      
   Furthermore, to prevent similar lingering misconceptions indexing is not   
   specified in the standards I'm looking at beyond that it's just pointer   
   arithmetic - that is, a pointer derived from an array-name may not be   
   used with pointer arithmetic /alone/ that adjusts the pointer down by   
   any nor up by more than the number of elements in the array + 1, and if   
   adjusted up by num_elements it can't be used with *. Note that in some   
   standards' final-drafts I see that intermediate (perhaps, generally,   
   non-lvalue) pointers may be created by pointer arithmetic when they are   
   de-created again - and perhaps the pattern of arithmetic is very limited.   
      
   Some standard version says if you convert it to a large enough integer   
   type and back then it is not undefined behaviour but   
   "implementation-specific" instead, which is a new term on me   
   ("implementation-specific" is not the same term as "implementation   
   specified").   
      
      
   ... pointer equality snipped ...   
      
      
   > The idea, I think, is that without that paragraph, given something like   
   > this:   
   >   
   > #include    
   > int main(void) {   
   >     struct {   
   >         int a[10];   
   >         int b[10];   
   >     } obj;   
   >   
   >     printf("obj.a+10 %s obj.b\n",   
   >            obj.a+10 == obj.b ? "==" : "!=");   
   > }   
   >   
   > the compiler would have to go out of its way to treat obj.a+10 and obj.b   
   > as unequal   
      
   No it wouldn't. The standard could have just made the comparison   
   undefined behaviour or unspecified, or implementation specified in all   
   those cases when dereferencing was undefined or unspecified.   
      
   --   
   Tristan Wibberley   
      
   The message body is Copyright (C) 2026 Tristan Wibberley except   
   citations and quotations noted. All Rights Reserved except that you may,   
   of course, cite it academically giving credit to me, distribute it   
   verbatim as part of a usenet system or its archives, and use it to   
   promote my greatness and general superiority without misrepresentation   
   of my opinions other than my opinion of my greatness and general   
   superiority which you _may_ misrepresent. You definitely MAY NOT train   
   any production AI system with it but you may train experimental AI that   
   will only be used for evaluation of the AI methods it implements.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)