Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The goal of science is to build better mousetraps. The goal of nature is to build better mice.


devel / comp.std.c / Type qualifiers and controlling expression of _Generic

SubjectAuthor
o Type qualifiers and controlling expression of _GenericTim Rentsch

1
Type qualifiers and controlling expression of _Generic

<867de3hxp3.fsf@linuxsc.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=379&group=comp.std.c#379

  copy link   Newsgroups: comp.std.c
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.std.c
Subject: Type qualifiers and controlling expression of _Generic
Date: Sat, 23 Oct 2021 21:08:08 -0700
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <867de3hxp3.fsf@linuxsc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="2c81915e152067623ac33dc03888a217";
logging-data="10918"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cdnOAgrVI94Y7KZQgtwUK9fLMg+tQAac="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:b1o7aWJEnJsiL1S0v2zGAsGMw4Q=
sha1:FTRXkOu6/+QAILifIDw7d9F8JjI=
 by: Tim Rentsch - Sun, 24 Oct 2021 04:08 UTC

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote in comp.lang.c++:

> I was curious so I tried this:
>
> #include <stdio.h>
>
> struct S { const int i; } s;
> struct S f(void) { return s; }
>
> int main(void)
> {
> const char *t =
> _Generic(f().i,
> int: "int",
> const int: "const int");
> puts(t);
> }
>
> f().i is not a lvalue and has a const-qualified type. gcc prints
> "int", but clang prints "const int". I think clang is right here.
> (So much for "they all copy gcc"!)

After looking into this, I reach a different conclusion.

First, despite the definition of lvalue conversion in 6.3.2.1 p2,
it appears that it was never intended that lvalue conversion
apply to expressions that are not evaluated. For C11, at the
last minute the _Alignof operator was added as an exception for
when lvalue conversions are done, but that was taken out again in
C17, and still is not present in n2731, which I believe is the
latest C2x draft. Also there is this defect report

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_423.htm

dated October 8, 2012, which shows that the problem was recognized
as a defect but not yet resolved about how to handle it. (That
defect report is fairly long so I won't try to summarize it.)

Second, the matter is addressed rather straightforwardly in C17
and later in n2731 (which can be gotten here

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf

), where 6.5.1.1 p2 (talking about _Generic) says in part

The type of the controlling expression is the type of the
expression as if it had undergone an lvalue conversion, [...]

with a reference to a footnote

An lvalue conversion drops type qualifiers.

I should add that as best I can tell the same wording is used in
C17 as in n2731 although I have not done a side-by-side comparison.

Thus, I conclude that type qualifiers are removed by the "as if"
lvalue conversion, whether or not the particular controlling
expression is an lvalue. What gcc does is right, and clang just
hasn't caught up to the latest corrections in this area.

Disclaimer: I have not done any experimentation either with gcc
or with clang to see how different versions or different option
settings might affect their behaviors.

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor