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

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>

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.

>
It does if the visible declaration has the same information.

>
Like 'restrict', parameter array length information, specified by
way of 'static', is ignored outside of function definitions.  As
was intended (with 'restrict' also).

>
? What "static" does when applied to an array parameter's length is to
render the behavior undefined if the function is called with a pointer
that points to an array that is shorter than the specified length.  Are
you saying that it has no such effect except for inside the function
definition?  I'm not sure what that would even mean - is the behavior
undefined only for recursive calls to the function?

What I mean is that such uses of 'static' have no effect when
used in declarations that are not part of a definition.

Furthermore, and also like 'restrict', there is no general
way to verify at compile time that the stipulated condition
holds.

>
As I already mentioned, if such verification could have been
generally possible, it should have been a constraint violation.
Because it is not possible in general, but only in certain cases,
making the behavior undefined is the best that can be done.  Doing
so encourages implementations to generate a diagnostic when those
cases do come up.

It isn't just that checking the condition cannot be done in general.
To be reliable the parameter length information would need to be
part of the function's type.  That has implications for type
compatibility and also for the types of pointers-to-function.  And
it would mean that removing a 'static' array length specification on
a function definition would necessitate also changing the functions
declarations, plus any affected pointers-to-function.  Not worth it,
even if in theory it were doable.

Considering the above, it's better to observe the status quo, and
leave any diagnostics up to the discretion of the implementation,
rather than try to retrofit an incompatible change that would
make an infringement be a constraint violation that can't be
checked anyway.

>
I was not suggesting any change to the status quo, [...]

I didn't mean to imply you had.