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

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

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.

It affects whether a program has defined or undefined behavior.
(Yes, a conforming compiler could ignore it.)

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.

Why would it not be present?

If you mean that someone might use `[static N]` in a function's
definition but not in a declaration, sure, but I would always
make sure they match as closely as possible.  And gcc and clang
(and possibly other compilers) will issue meaningful warnings on
the basis of `[static N]` in a function declaration, even if that
declaration is not part of a definition.

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.

And as you seem to have agreed, nobody suggested that.  Were we
supposed to guess what it's better than?  Or did I miss something?

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.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */