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


Groups > comp.std.c > #1381

Re: qualified rvalues

Message-ID <4FE64CA4.1020402@loria.fr> (permalink)
Date 2012-06-24 01:09 +0200
From Jens Gustedt <jens.gustedt@loria.fr>
Newsgroups comp.std.c
Subject Re: qualified rvalues
References <4FE5C464.5090305@loria.fr> <17phb9-agb.ln1@jones.homeip.net>
Organization Guest of ProXad - France

Show all headers | View raw


Hello,

Am 23.06.2012 23:31, schrieb lawrence.jones@siemens.com:

> The other relevant passages are 6.7.3p4:
> 
> 	The properties associated with qualified types are meaningful
> 	only for expressions that are lvalues.

Hm, but doesn't this just say that other values may also have
qualified types? And that only the associated specific properties make
not much sense, which is clear for const, volatile and _Atomic. (I had
to think a bit for finding the idea natural for restrict.)

But it says that they can have such a type, and so a tool like
_Generic that explicitly asks for the type and not for any of the
associated properties has to distinguish them, no?

> (which is the justification for the above footnote [104 in C11]), and
> 6.3.2.1p2:

> 	Except when it is the operand of the sizeof operator, the unary
> 	& operator, the ++ operator, the -- operator, or the left
> 	operand of the . operator or an assignment operator, an lvalue
> 	that does not have array type is converted to the value stored
> 	in the designated object (and is no longer an lvalue); this is
> 	called /lvalue conversion/. If the lvalue has qualified type,
> 	the value has the unqualified version of the type of the lvalue;

As I said in my other post (that nobody commented so far) I don't
think that this para applies to primary expressions such as () and
_Generic. They are not operators, their argument expressions are
not operands and the whole section of conversion (that talks of
operands) doesn't apply.

>> That could mean two things:
>>
>> (1) the effective type of the resulting rvalue is unqualified
>> (2) all operators that will accept the rvalue as an operand will act
>>     all the same whether the type is qualified or not

> Based on the above, I believe that (1) was what the committee intended.

You didn't convince me, yet. If that had been the intention since C99
(the texts you cite are identical since then, I think) this should
have been explicitly stated. I am still convinced that it just was not
though of, set aside or something, because it was not observable
before.

And we are obviously in the situation that compilers interpret that
differently.

Jens

Back to comp.std.c | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

qualified rvalues Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-23 15:28 +0200
  Re: qualified rvalues lawrence.jones@siemens.com - 2012-06-23 17:31 -0400
    Re: qualified rvalues Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-24 01:09 +0200

csiph-web