Re: Loops (was Re: do { quit; } else { })

On 11/05/2025 23:43, James Kuyper wrote:

On 5/11/25 06:02, David Brown wrote:

On 11/05/2025 10:21, Muttley@dastardlyhq.com wrote:

On Sat, 10 May 2025 14:29:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> gabbled:

...

The use I'm talking about here may be illustrated as follows:
>
    double
    average( double values[ static 10 ] ){
       double total = 0;
       for(  int i = 0;  i < 10;  i++  ){
          total += values[i];
       }
       return  total / 10;
    }
>
What word would you suggest to be used in place of 'static'
there?

>
If I knew what the hell it was supposed to do I'd tell you.
>

>
Using "static" inside array parameters is, IME, extremely rare.  It was
added in C99, and tells the compiler that whenever "average" is called,
the "values" parameter points to an array of at least 10 doubles.  It

 More precisely, it makes it undefined behavior for values to point to an
array of less than 10 doubles.
 

The wording of the C standard (C11, as that's what I have open at the moment) is :
"""
If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression.
"""
I think my wording is at least as "precise" as yours.  The potential UB here comes from violating the "shall" requirement.

does not affect the signature of the function or compatibility with any
other declarations, and is AFAIK rarely checked by compilers.

 I'd have preferred it if violating that requirement was a constraint
violation, but it can't be, because there are many cases where a
compiler cannot be sure how long the array is that a pointer points at.

Indeed.  I am also a big fan, in general, of making mistakes in code into compiler errors when possible - I'd rather the compiler found my bugs than leave it to run-time testing!

However, the fact that the behavior is undefined justifies a compiler
reacting to the case when it can be sure that the requirement will be
violated.

Unfortunately, that is not quite true.  A C programmer is free to write whatever nonsense and run-time UB they like, as long as that UB is not actually "executed".  So a compiler, if it aims to be conforming and to accept code with well-defined behaviour, has to be sure that the bad code in question would inevitably be executed before it is justified in rejecting the code with an error.
(When the user has asked for non-conforming behaviour, or additional analysis and warnings, then of course the compiler can complain when it sees a potential error.  Such warnings are almost always a good idea.)

That's the main reason I like this feature, and dislike
compilers that fail to take advantage of that opportunity. I never
considered it to be about efficiency, though there are cases where it
can result in more efficient code.
 

The C99 rational says it was added for efficiency reasons.  But often efficiency and static error analysis go together - the more information the compiler has, the better it is at both tasks.  And I agree with your attitude of emphasising the static error analysis as being more important than the efficiency considerations in most cases.

In an example like the one above, it is completely useless for
compilation - it tells the compiler nothing that it does not already
know.  An optimising compiler will see that you are accessing values[0]
to values[9], and if it can get better results through vectorising,
prefetching, etc., then it will do so.  (You can argue that the "static
10" is still useful as an indicator to human readers, but I am not
convinced of that.)

 It's main potential usefulness is not in the definition of the function,
but in calls to the function. If the calls occur in a different
translation unit from the definition, the compiler does not have the
needed information.

That is the case for its potential usefulness in static error checking, but not the case for its potential usefulness in optimisation.
I am not convinced that it is actually useful as an error checking mechanism in many situations.  In a lot of code, you simply don't have a compile-time checkable array sizes - you have a pointer, and a run-time variable for the size.  When you are calling your function with a "static" array size, the compiler does not have any way to check your pointer for correctness.
This is why some compilers and other verification tools have extensions that can do more than "static" array parameters can - gcc's "access" attribute and "object size" builtins are examples.
Still, even if it only helps occasionally, that's better than no help at all.