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


Groups > comp.std.c > #1379

qualified rvalues

Path csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!usenet-fr.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp6-1.free.fr!not-for-mail
Message-ID <4FE5C464.5090305@loria.fr> (permalink)
Date Sat, 23 Jun 2012 15:28:04 +0200
From Jens Gustedt <jens.gustedt@loria.fr>
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version 1.0
Newsgroups comp.std.c
Subject qualified rvalues
Content-Type text/plain; charset=ISO-8859-15
Content-Transfer-Encoding 7bit
Lines 60
Organization Guest of ProXad - France
NNTP-Posting-Date 23 Jun 2012 15:28:04 CEST
NNTP-Posting-Host 81.56.96.245
X-Trace 1340458084 news-3.free.fr 1738 81.56.96.245:54007
X-Complaints-To abuse@proxad.net
Xref csiph.com comp.std.c:1379

Show key headers only | View raw


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

Back to comp.std.c | Previous | Next — Next 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