Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #161942

Re: Array is an non-modifiable lvalue - where does it matter?

From Kaz Kylheku <563-365-8930@kylheku.com>
Newsgroups comp.lang.c
Subject Re: Array is an non-modifiable lvalue - where does it matter?
Date 2021-07-16 22:21 +0000
Organization A noiseless patient Spider
Message-ID <20210716145835.570@kylheku.com> (permalink)
References <scq5c5$tql$1@dont-email.me>

Show all headers | View raw


On 2021-07-15, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> 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?

If what you are getting at is this: could a C dialect provide complete
support for array passing, returning and assignment, while conforming
to the current standard?

The answer is no.

A conforming extension of behavior could be to allow arrays to be
modifiable lvalues: emit the required diagnostic, and then allow
assignment or initialization; e.g.

  int a[10] = { 0 };
  int b[10] = a;
  int c[10];
  c = b;

FUrthermore, function declaration syntax for returning arrays could
be added without conflict:

  int foo(void)[10];
  c = foo();

Where we run aground is the fact that parameter declarations of
array type actually declare a pointer. This is the case even
if they specify a dimension:

  void foo(int a[42]); // actually (int *a)

that kind of puts a monkey wrench into an otherwise reasonably
tidy plan to extend the language.

Passing arguments to parameters is very similar to assignment;
An assignable array proposal which doesn't permit passing would
introduce an ugly inconsistency.

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

Indeed, an implementation can implement the constraint that arrays are not
modifiable lvalues simply by imposing the "decay rule" in all contexts
other than when the array is the operand of & (address-of) or sizeof.

The array is then not assignable by virtue of having been converted
to a pointer which is not an lvalue. If it's not an lvalue, it's not
a modifiable lvalue: requirement satisfied.

> Am I right here? Is the constraint of 6.5.16/2 supposed to be applied 
> before automatic implicit conversions or after them?

It looks moot. Before conversion to pointer, you have an array lvalue,
and the requirement says that it' not modifiable. Thus, cannot assign to
it. After conversion to pointer, you don't have an lvalue. Not
assignable, either.

Which case it is basically is only germane to the wording of the
constraint violation diagnostic, and that is not specified.

A compiler which diagnoses the assignment as "cannot assign to a
calculated pointer" is conforming; it has produced the required
diagnostic.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-15 13:21 -0700
  Re: Array is an non-modifiable lvalue - where does it matter? Öö Tiib <ootiib@hot.ee> - 2021-07-15 13:55 -0700
    Re: Array is an non-modifiable lvalue - where does it matter? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-15 22:12 +0100
      Re: Array is an non-modifiable lvalue - where does it matter? Öö Tiib <ootiib@hot.ee> - 2021-07-15 15:07 -0700
        Re: Array is an non-modifiable lvalue - where does it matter? David Brown <david.brown@hesbynett.no> - 2021-07-16 09:52 +0200
          Re: Array is an non-modifiable lvalue - where does it matter? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-16 02:31 -0700
          Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-16 10:59 -0700
            Re: Array is an non-modifiable lvalue - where does it matter? David Brown <david.brown@hesbynett.no> - 2021-07-17 16:23 +0200
              Re: Array is an non-modifiable lvalue - where does it matter? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-17 20:14 -0400
    Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-15 14:36 -0700
      Re: Array is an non-modifiable lvalue - where does it matter? Öö Tiib <ootiib@hot.ee> - 2021-07-15 15:19 -0700
  Re: Array is an non-modifiable lvalue - where does it matter? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-15 14:06 -0700
  Re: Array is an non-modifiable lvalue - where does it matter? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-16 14:22 -0400
    Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-16 11:43 -0700
      Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-17 18:24 -0700
        Re: Array is an non-modifiable lvalue - where does it matter? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-17 20:29 -0700
        Re: Array is an non-modifiable lvalue - where does it matter? Siri Cruise <chine.bleu@yahoo.com> - 2021-07-17 21:25 -0700
    Re: Array is an non-modifiable lvalue - where does it matter? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-16 15:22 -0700
  Re: Array is an non-modifiable lvalue - where does it matter? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-16 22:21 +0000
    Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-16 23:27 -0700
      Re: Array is an non-modifiable lvalue - where does it matter? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-17 16:53 +0000
        Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-17 10:49 -0700
        Re: Array is an non-modifiable lvalue - where does it matter? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-17 14:01 -0700
      Re: Array is an non-modifiable lvalue - where does it matter? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-18 02:09 +0100
    Re: Array is an non-modifiable lvalue - where does it matter? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-17 20:12 -0400
  Re: Array is an non-modifiable lvalue - where does it matter? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-17 13:20 -0700
    Re: Array is an non-modifiable lvalue - where does it matter? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-19 14:44 -0700
      Re: Array is an non-modifiable lvalue - where does it matter? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-23 23:26 -0700

csiph-web