Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson 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: <20250415153419.00004cf7@yahoo.com> <86h62078i8.fsf@linuxsc.com> <20250504180833.00000906@yahoo.com> <86plggzilx.fsf@linuxsc.com> <86ldr4yx0x.fsf@linuxsc.com> <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 writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >>>> James Kuyper 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 */