Deutsch English Français Italiano |
<86o6vyxoit.fsf@linuxsc.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch <tr.17687@z991.linuxsc.com> Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Mon, 12 May 2025 00:43:22 -0700 Organization: A noiseless patient Spider Lines: 59 Message-ID: <86o6vyxoit.fsf@linuxsc.com> References: <vspbjh$8dvd$1@dont-email.me> <20250413072027.219@kylheku.com> <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> <vvrs5j$t9go$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 12 May 2025 09:43:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="74b4e5895be58ca73eb02e8f9ff401e1"; logging-data="1024033"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/md4REIh2uapN+oOX6E2nt6REhdCeFn5c=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:4VmdJpbZf4v8WQau8hfe8FXymQc= sha1:lxd2wEq9w70T6rpu6EtTkg25V20= Bytes: 4298 James Kuyper <jameskuyper@alumni.caltech.edu> 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). > > ? What "static" does when applied to an array parameter's length is to > render the behavior undefined if the function is called with a pointer > that points to an array that is shorter than the specified length. Are > you saying that it has no such effect except for inside the function > definition? I'm not sure what that would even mean - is the behavior > undefined only for recursive calls to the function? What I mean is that such uses of 'static' have no effect when used in declarations that are not part of a definition. >> Furthermore, and also like 'restrict', there is no general >> way to verify at compile time that the stipulated condition >> holds. > > As I already mentioned, if such verification could have been > generally possible, it should have been a constraint violation. > Because it is not possible in general, but only in certain cases, > making the behavior undefined is the best that can be done. Doing > so encourages implementations to generate a diagnostic when those > cases do come up. It isn't just that checking the condition cannot be done in general. To be reliable the parameter length information would need to be part of the function's type. That has implications for type compatibility and also for the types of pointers-to-function. And it would mean that removing a 'static' array length specification on a function definition would necessitate also changing the functions declarations, plus any affected pointers-to-function. Not worth it, even if in theory it were doable. >> 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. > > I was not suggesting any change to the status quo, [...] I didn't mean to imply you had.