Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Const-qualified function return type in C - is it a part of function type?
Date: Sat, 22 Feb 2020 09:53:40 -0800
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <861rqmcxuj.fsf@linuxsc.com>
References: <r2plun$4vl$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="a1e79922b2c02e9149a52088916eaff2"; logging-data="18359"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/N/nBofmHCeD0LwZTHIH2q4KWAKkA3Cgw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:9n3YDxNwQrIZTOKcV9lj4atLF4g= sha1:b9FQEMd/FZ32Sz1GPV22ejFpOos=
Xref: csiph.com comp.lang.c:150155

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> Here's the code
>
>   const int foo() { return 42; }
>
>   int main()
>   {
>     int (*pFunc)() = foo;
>   }
>
> (In C++ mode both GCC and Clang reject this code, which is expected.)
>
> When this code is compiled as C, GCC remains completely quiet, even in
> presence of `-pedantic`. Clang always issues a warning about the types
> being incompatible.  In `-pedantic-errors` mode Clang flags this as an
> error.
>
> So, what is it really?
>
> On the one hand, `const` in this case is applied to something that is
> definitely not an lvalue, which makes it "meaningless" per 6.7.3/5
> ("The properties associated with qualified types are meaningful only
> for expressions that are lvalues.")
>
> On the other hand, the concept of *compatible type* does not in any
> way rely on expression-specific context and on the concept of lvalue,
> which seems to suggest that Clang is right:  the types are not
> compatible here.

I agree with your statements downthread.  What clang does is
right, and what gcc does is wrong.  What the Standard says is
confusingly worded, but I don't see any other way to make
sense of it reasonably than to say const qualifiers on some
consituent elements of a function such (such as the return type
or parameter types) is /not/ what is being talked about in the
now-infamous sentence

    If the specification of a function type includes any type
    qualifiers, the behavior is undefined.

which indeed is meant to refer only to qualifiers on the function
type as a whole, not to qualifiers on any constitutent elements.

Sorry for the absurdly overly long sentence there;  I don't have
time to make it shorter.