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 19:04:20 -0700
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <867c2lxo4b.fsf@linuxsc.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> <vvrs5j$t9go$1@dont-email.me> <86o6vyxoit.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 13 May 2025 04:04:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2fbcfbf8f4ee6298a3bd638090042c8c";
	logging-data="1622676"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+j0qAceSo6KuFXiAJtWxK/aOp8kcdpYmc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:C+WUw7M02mG0b7T6wmcYZwO8KeU=
	sha1:lJokeC3AMU7NIQe31RDufb11DA8=
Bytes: 3940

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

I need to correct myself.  This statement is simply wrong.  Giving a
parameter declarator a 'static' length specification, as part of any
function declaration whatsoever, has the same effect as it would if
it had been given on the function definition.  To present an example,
if we have three source files, x.c, y.c, and z.c, with

   /* x.c */
   int foo( int v[] );

   int
   example(){
      return foo( 0 );
   }


   /* y.c */
   int
   foo( int v[] ){
      return  v ? v[0] : -1;
   }


   /* z.c */
   int foo( int v[ static 1 ] );


then because of the declaration of foo() in z.c, the call to foo()
in x.c has undefined behavior, because a "shall" requirement is
violated by passing a null pointer for parameter v, which must
point to an array with at least one element.

As best I can determine the description of how 'static' works in
such cases has not changed since its original introduction in C99
up to the present.