From: tristan.wibberley+netnews2@alumni.manchester.ac.uk   
      
   On 13/01/2026 23:53, Tristan Wibberley wrote:   
   > Combining these, and padding requirements, you can definedly reach   
      
   I recall padding requirements for the extremes of array object types   
   from discussions on usenet years ago, however, perhaps they were for C++   
   because I can find nonsuch, nonsuch at all, not even the slightest peep,   
   in the standard final-drafts. There are several lingering evidences of   
   the requirement to have no padding even at the extremes of arrays with   
   element size 2 and above but all direct statement of such is missing.   
   The lingering evidence leaves a nondeterminism or unspecified nature to   
   some matters such as whether sizeof includes any padding at the extremes   
   of an array or not, while it is explicit about the matter for structs   
   and unions.   
      
   Even the example in the drafts of the use of sizeof array/sizeof   
   array[0] to determine the number of objects is excluded for arrays with   
   elements of size 1 due to being unspecified by the standard by the   
   decree of the limitation in the section on representation that all   
   representation constraints are found in that section alone and are   
   otherwise unspecified.   
      
   No constraints on representation of arrays is provided in any way   
   because the contiguousness of elements is mooted outside the   
   representation subclause, as is the sizeof trick, and the sizeof trick   
   can only work if the array is represented as contiguous representations   
   of its elements and is represented with no padding at its extremes,   
   neither of which is stipulated in the representation subclause that   
   allows stipulations on the matter only within its own bounds.   
      
   Furthermore, the representation stipulation horizon is in the "General"   
   subclause preventing the "integer types" subclause from effecting   
   specifications of representations.   
      
   If the drafts I can see actually reflect the standards as they were   
   rather than merely a history of them as the history now is then it was   
   always impractical to use ISO C anywhere a system had to be safe to use   
   and nearly all advice from outside the standard was unreliable and some   
   of the advice within it. An implementers document for C implementations   
   that ought be implemented but ought not have any programs to translate.   
      
   I have to recommend avoiding it everywhere that matters.   
      
   --   
   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)