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

Groups > comp.std.c > #1379 > unrolled thread

qualified rvalues

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

Contents

  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

#1379 — qualified rvalues

Hi,
I have the impression that the dealing of rvalues with qualified types
is largely underspecified. It was so even before C11 but that problem
only surfaces now, since with _Generic type qualifications of
values have become observable.

In essence I didn't find that the standard has much to say when it
comes to qualified types for rvalues. They definitively do exist,
since the cast operator explicitly specifies that the type could be
qualified. The section on casts also has the only indication I found
that relates to rvalues. There is a footnote (thus not normative) that
says

 > 89) A cast does not yield an lvalue. Thus, a cast to a qualified
> type has the same effect as a cast to the unqualified version of the
> type.

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

doing some tests I have found that clang and gcc disagree on this
point. (gcc doesn't have _Generic, yet, but other builtins to observe
types)

clang seems to implement (1), gcc (2). They agree for lvalues like
this

_Generic((double const){ 0 },
         default: 0,
         double const: 1)

both evaluate it to 1.

They disagree on the outcome for rvalues

_Generic((double const)0,
         default: 0,
         double const: 1)

clang gives 0, gcc gives 1.

(for gcc all with caution that it doesn't have _Generic yet, but that
I am using an emulation of it by means of other gcc builtins)

I think that this is not a defect of the _Generic construct itself but
a lack of specification for types of value expression. The easiest to
fix this would be, I think, to specify that (1) happens, that is all
casts result in types that have no qualification, and, that functions
always return unqualified types, even the specification has one.

Then, only lvalues could have qualified types. (lvalue conversion
drops qualifiers, arrays can't be qualified by themselves)

On the other hand the consequence that the two _Generic expressions
above would return different values could be quite surprising.

Jens

[toc] | [next] | [standalone]

#1380

Jens Gustedt <jens.gustedt@loria.fr> wrote:
> 
> In essence I didn't find that the standard has much to say when it
> comes to qualified types for rvalues. They definitively do exist,
> since the cast operator explicitly specifies that the type could be
> qualified. The section on casts also has the only indication I found
> that relates to rvalues. There is a footnote (thus not normative) that
> says
> 
>  > 89) A cast does not yield an lvalue. Thus, a cast to a qualified
> > type has the same effect as a cast to the unqualified version of the
> > type.

The other relevant passages are 6.7.3p4:

	The properties associated with qualified types are meaningful
	only for expressions that are lvalues.

(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;

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

Who, ME?  Who?! Me??  WHO... Me?!  Who, me??? -- Calvin

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

#1381

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

[toc] | [prev] | [standalone]

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

csiph-web