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

Groups > comp.lang.c > #161918 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#161949

On 2021-07-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 7/16/2021 3:21 PM, Kaz Kylheku wrote:
>> 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.
>
> No, no, no, I'm not interested in that at all.
>
>>> 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.
>> 
>
> Yes, it is moot for the specific case of arrays.
>
> But at the same time it intuitively looks and feels like a more general 
> issue. Again, what comes first: automatic implicit conversions or 
> constraint checks?

In "array = foo", there is no implicit conversion of array. It is
an lvalue of array type and remains that way.

If the assignment were allowed, then how it would likely work is
that the "array = foo" expression, as a whole would implicitly convert
to a pointer but not "array" itself.

This is analogous to i = j = 0, j is an lvalue and stays that way.
However (j = 0) isn't an lvalue.

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

[toc] | [prev] | [next] | [standalone]

#161950

On 7/17/2021 9:53 AM, Kaz Kylheku wrote:
> On 2021-07-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 7/16/2021 3:21 PM, Kaz Kylheku wrote:
>>> 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.
>>
>> No, no, no, I'm not interested in that at all.
>>
>>>> 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.
>>>
>>
>> Yes, it is moot for the specific case of arrays.
>>
>> But at the same time it intuitively looks and feels like a more general
>> issue. Again, what comes first: automatic implicit conversions or
>> constraint checks?
> 
> In "array = foo", there is no implicit conversion of array. 

That's not true. In `array = foo` the left-hand side is implicitly 
converted to pointer type (under assumption that constraints are checked 
after applying automatic implicit conversions).

> It is an lvalue of array type and remains that way.

That is completely false. Remember that value categories refer to 
expression results, not to objects themselves.

Since simple contextless `array` expression is not excluded from 
decaying contexts by 6.3.2.1/3, `array` itself (as an expression) is an 
rvalue of pointer type.

The same can be said of LHS of assignment: it is an rvalue of pointer 
type (again, under assumption that constraints are checked after 
applying automatic implicit conversions).

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#161952

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-17, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 7/16/2021 3:21 PM, Kaz Kylheku wrote:
>>> 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.
>>
>> No, no, no, I'm not interested in that at all.
>>
>>>> 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.
>>> 
>>
>> Yes, it is moot for the specific case of arrays.
>>
>> But at the same time it intuitively looks and feels like a more general 
>> issue. Again, what comes first: automatic implicit conversions or 
>> constraint checks?
>
> In "array = foo", there is no implicit conversion of array. It is
> an lvalue of array type and remains that way.

I don't believe that's correct.  `array` is an expression of array type
(whether it's an lvalue or not).  The standard specifies three contexts
in which such an expression is not converted a pointer expression (N1570
lists 4, but it's incorrect).  The LHS of an assignment is not one of
those contexts.

If the conversion did not apply, the assignment would be a constraint
violation because `array` is not a *modifiable* lvalue.  But the
conversion does apply, and so the assignment is a constraint violation
because, after the conversion, `array` is a non-lvalue expression of
pointer type.

Of course it doesn't matter *why* it's a constraint violation, as long
as the implementation issues a diagnostic.

> If the assignment were allowed, then how it would likely work is
> that the "array = foo" expression, as a whole would implicitly convert
> to a pointer but not "array" itself.
>
> This is analogous to i = j = 0, j is an lvalue and stays that way.
> However (j = 0) isn't an lvalue.

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

[toc] | [prev] | [next] | [standalone]

#161956

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 7/16/2021 3:21 PM, Kaz Kylheku wrote:
>> 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.
>
> No, no, no, I'm not interested in that at all.
>
>>> 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.
>> 
>
> Yes, it is moot for the specific case of arrays.
>
> But at the same time it intuitively looks and feels like a more
> general issue. Again, what comes first: automatic implicit conversions
> or constraint checks?

That the /intent/ is that the constraints apply after these conversions
is obvious from many other common situations.  For example, given

  int array[2];
  void f(void);

both *array and f() would be constraint violations unless the
conversions in section 6.3.2.1 are applied first.

> And even if this currently proves to be moot in all other contexts as
> well, it still appears to be something kinda... too important to be
> left unspecified.

Is it clearly specified?  I don't know.  I've never thought it could be
taken any other way, but the fact that you were not sure makes this
obviously wrong.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#161954

On 7/16/21 6:21 PM, Kaz Kylheku wrote:
> 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?

I doubt that he's trying to "get at" anything. As I read his message, it
appears that he found a clause in the standard whose purpose he did not
understand, and he's asking for an explanation of it. You're reading far
too much into his question.

[toc] | [prev] | [next] | [standalone]

#161951

On 7/15/2021 1:21 PM, Andrey Tarasevich 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?
> 
> 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?
> 

I must be missing something. Fwiw, sometimes I wrap fixed arrays in 
structs just to be able to copy them via assignment:
__________________________________
#include <stdio.h>


#define FOO_N 50


struct array
{
     int foo[FOO_N];
};


int main()
{
     struct array data_0 = { 0 };
     struct array copy_0 = data_0;

     copy_0.foo[42] = 42;

     printf("data_0::foo[%u] = %d\n", 42, data_0.foo[42]);
     printf("copy_0::foo[%u] = %d\n", 42, copy_0.foo[42]);

     return 0;
}
__________________________________

[toc] | [prev] | [next] | [standalone]

#161976

On 7/17/2021 1:20 PM, Chris M. Thomasson wrote:
> On 7/15/2021 1:21 PM, Andrey Tarasevich 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?
>>
>> 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?
>>
> 
> I must be missing something. Fwiw, sometimes I wrap fixed arrays in 
> structs just to be able to copy them via assignment:
> 

And? In my question I'm talking about behavior of expressions of array 
type and how language constraints are checked against such expressions.

Copying arrays wrapped in structs has nothing to do with that topic. And 
yes, you can copyin arrays wrapped in structs.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#162048

On 7/19/2021 2:44 PM, Andrey Tarasevich wrote:
> On 7/17/2021 1:20 PM, Chris M. Thomasson wrote:
>> On 7/15/2021 1:21 PM, Andrey Tarasevich 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?
>>>
>>> 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?
>>>
>>
>> I must be missing something. Fwiw, sometimes I wrap fixed arrays in 
>> structs just to be able to copy them via assignment:
>>
> 
> And? In my question I'm talking about behavior of expressions of array 
> type and how language constraints are checked against such expressions.
> 
> Copying arrays wrapped in structs has nothing to do with that topic. And 
> yes, you can copyin arrays wrapped in structs.
> 

I missed your point. Sorry. ;^/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web