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:
>

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.)

Please read again what I said:  parameter array length information,
specified by way of 'static', is ignored _outside of function
definitions_.

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. [...]

It strikes me that you have a rather self-centered view of the
world.  The vast majority of all C code is written by people other
than yourself.

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?

There was no reason to guess, because it was written in plain
English in the earlier posting.