Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Usage of static in array declaration
Date: Fri, 10 Sep 2021 11:26:07 -0700
Organization: None to speak of
Lines: 55
Message-ID: <87czpgffsw.fsf@nosuchdomain.example.com>
References: <51e13b69-37ba-46e1-95eb-f30dd76590efn@googlegroups.com> <b21d04d8-b701-4f38-8398-abac128dae38n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="0e9d3ba203e9f9b63058110a571a6640"; logging-data="15058"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/s2rf+EyEP85bOnOb52X+q"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:jOkQLM5z4kjkoisuRJXpMtcVCjg= sha1:KhjtIGbKEm44HRaM493jd+dcFxU=
Xref: csiph.com comp.lang.c:162715

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> On Friday, September 10, 2021 at 10:39:06 AM UTC-4, Thiago Adams wrote:
>> It is not clear to me why this static was created and 
>> what is the behavior. 
>> 
>> For instance, 
>> void F(char name[static 10]){ 
>> } 
>> 
>> Can I pass a pointer to char*?
>
> Sure. If you ignore the "static", that declaration is equivalent to "char *name".
> The static keyword imposes restrictions on the values that you can safely
> pass to the function, but has no effect on the types that you can pass.
>
> "If the keyword static also appears within the [ and ] of the array type
> derivation, then for each call to the function, the value of the corresponding
> actual argument shall provide access to the first element of an array with at
> least as many elements as specified by the size expression." (6.7.6.3p7).
>
> Note that this is a "shall" that does not occur in a constraints section. As
> such, code which violates this "shall" has undefined behavior (4p2). No
> diagnostic is required. This is because it could be arbitrarily difficult to
> determine at compile time whether or not that is the case. However, good
> quality implementation should generate a diagnostic whenever they can
> determine that it is violated, and that optional diagnostic is, in my opinion,
> the main justification for this feature. I've heard it claimed that it enables
> optimizations, but I've never heard an explanation of what those
> optimizations might be.

Right.  All the "static" keyword does is cause some calls to have
undefined behavior that would not have UB if the "static" were removed.

A naive compiler can treat `char name[static 10]` as exactly equivalent
to `char name[]` or `char *name`.

A sufficiently clever compiler can use the `static 10` to warn about
possible undefined behavior (though there will always be cases where it
can't do so reliably) and generate code in a way that assumes the
behavior is well defined.

For example:

    void F(char name[static 10]) {
        if (name != NULL) {
            /* ... */
        }
    }

An optimizing compiler could remove the NULL check.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */