Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Mon, 12 May 2025 02:23:59 -0700
Organization: None to speak of
Lines: 71
Message-ID: <874ixq41xs.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$1@dont-email.me> <vtgpce$39229$1@dont-email.me>
	<vti2ki$g23v$1@dont-email.me> <vtin99$vu24$1@dont-email.me>
	<vtiuf0$18au8$1@dont-email.me> <vtj97r$1i3v3$1@dont-email.me>
	<vtl166$36p6b$1@dont-email.me> <vtlcg0$3f46a$2@dont-email.me>
	<20250415153419.00004cf7@yahoo.com> <86h62078i8.fsf@linuxsc.com>
	<20250504180833.00000906@yahoo.com> <86plggzilx.fsf@linuxsc.com>
	<vvnsvt$3k1mu$1@dont-email.me> <86ldr4yx0x.fsf@linuxsc.com>
	<vvpmm2$3dhl$1@dont-email.me> <vvpsji$4jht$1@dont-email.me>
	<vvr5mg$l85c$1@dont-email.me>
	<87wmam4xa5.fsf@nosuchdomain.example.com> <868qn2zl1m.fsf@linuxsc.com>
	<87jz6m4m2o.fsf@nosuchdomain.example.com> <86selaxprh.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 12 May 2025 11:24:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ec3410180c1ee7cec196ae011e16bd7a";
	logging-data="1079177"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+wafKHk2qNuRrRwNikvah3"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:FhuprmAG9EDjsNyXDdyO8k/74wo=
	sha1:lHHnNdbE+F+eBDXDNz+NArk4KFE=

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 */