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: Array is an non-modifiable lvalue - where does it matter?
Date: Thu, 15 Jul 2021 14:06:40 -0700
Organization: None to speak of
Lines: 50
Message-ID: <87im1b2snz.fsf@nosuchdomain.example.com>
References: <scq5c5$tql$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ea9f25db98250ad3c2095bb4c90a3161"; logging-data="11401"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19UFFySqsfOhb5xPftIk7/X"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:RPGlun8TnrC+5TfbFBNzmUL3qS0= sha1:PHS7bfoGHYx8aWAqGAQ3DoYromk=
Xref: csiph.com comp.lang.c:161920

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 6.3.2/1 says that
>
>   1 [...] A modifiable lvalue is an lvalue that does not have array
>   type, [...]
>
> Based on that, arrays are non-modifiable lvalues. We all know what it
> actually means. But is there any context in the standard in which this 
> non-modifiability of array lvalues would actually _matter_, would
> actually interact with some other standard requirement?
>
> One thing that comes to mind is a constraint on assignment operators
> (6.5.16/2)
>
>   2 An assignment operator shall have a modifiable lvalue as its left
>   operand.
>
> So, one can combine 6.3.2/1 and 6.5.16/2 and conclude that one can't
> assign to arrays. But I believe that constraints are intended/supposed 
> to be applied after automatic implicit conversions. And since LHS of
> assignment is not one of the contexts excluded from array type decay, 
> said decay is already sufficient to prevent assignment to arrays.
>
> Am I right here? Is the constraint of 6.5.16/2 supposed to be applied
> before automatic implicit conversions or after them?
>
> And if the answer is "after", then is there any other context in C
> standard where non-modifiability of array lvalues would make a
> difference?

My first thought is that the statement is redundant (and that's not
necessarily a bad thing).  Other requirements imply that you can't
assign to arrays, but it doesn't hurt to have an explicit statement to
that effect.

The full definition is:

    A *modifiable lvalue* is an lvalue that does not have array
    type, does not have an incomplete type, does not have a const-
    qualified type, and if it is a structure or union, does not have
    any member (including, recursively, any member or element of
    all contained aggregates or unions) with a const- qualified type.

I *think* that dropping the "does not have array type" wouldn't change
anything, but it's probably clearer as it is.

-- 
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 */