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.