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

Keith Thompson <Keith.S.Thompson+u@gmail.com> 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).

>
I think that by "is ignored", you mean that compilers are not
required to pay attention to it.  [...]

I mean it has no effect on program semantics.

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

>
Right, but that doesn't prevent implementations from issuing
useful warnings when it can determine that the stipulated
condition does not hold.

True, but in many cases they can't, because that information
is not part of the function's type and so often it is not
present.

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.

>
Observing the status quo is better than what, exactly?

Better than than trying to retrofit an incompatible change that
would make an infringement be a constraint violation that can't
be checked anyway.

The status quo is that the "[static N]" syntax has been in the
language since C99, and programmers and implementations are free
to take advantage of it.  I don't recall anyone in this thread
proposing a change to that.

Neither do I, nor did I mean to imply that anyone had.