clang, gcc, and ignored qualifiers: who is right?

Question

I found a difference in behavior between gcc and clang when compiling BoringSSL, and was able to whittle it down to the following test case to illustrate:

typedef char *OPENSSL_STRING;
#if USE_TYPEDEF
#define constptr const OPENSSL_STRING
#else
#define constptr const char *
#endif

int
foo (const void **ap)
{
    constptr a = (constptr) *ap;
    return a != 0;
}

I tested four scenarios as follows:

sh$ g++ -c t2.cc -Wignored-qualifiers -DUSE_TYPEDEF
t2.cc: In function ‘int foo(const void**)’:
t2.cc:11:30: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
   11 |     constptr a = (constptr) *ap;
      |                              ^~
sh$ g++ -c t2.cc -Wignored-qualifiers 
sh$ clang++ -c t2.cc -Wignored-qualifiers -DUSE_TYPEDEF
sh$ clang++ -c t2.cc -Wignored-qualifiers 
sh$

Is this a bug in gcc -- or is there something more going on that I don't understand?

For reference: the warning is in BoringSSL's stack.h

The existence of this macro is utterly baffling. Both branches are identical. — tadman, Feb 26 '21 at 15:05
Warnings are just warnings.... See C++ standard like [n3337](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf) and write your own [GCC plugin](https://gcc.gnu.org/onlinedocs/gccint/Plugins.html) to produce more warnings — Basile Starynkevitch, Feb 26 '21 at 15:07
Is that macro from, or totally representative of, BoringSSL? It seems broken _and_ pointless. — underscore_d, Feb 26 '21 at 15:12

songyuanyao · Accepted Answer · 2021-02-26T15:18:54.837

5

Given const OPENSSL_STRING, const is qualified on the typedef OPENSSL_STRING itself, so the type would be char * const, i.e. const pointer to non-const char (note that it's not const char *). Gcc is just trying to tell you that as the cast result the const part is ignored. i.e. (char * const) *ap; has the same effect as (char *) *ap;.

Changing the type to int might be clearer.

const int i = (int) 0;       // a weird conversion
const int i = (const int) 0; // same effect as above

edited Feb 26 '21 at 15:18

answered Feb 26 '21 at 15:08

songyuanyao

169,198
16
310
405

So the macro seems broken, right? Or at least, it doesn't do what e.g. tadman in the comments intuitively thought/expected it to do, and there's no apparent reason for it to exist either way. – underscore_d Feb 26 '21 at 15:11
Oh, I see! So it's clang that should complain about it, but does not. – Dmitri Feb 26 '21 at 15:12
@underscore_d I'm not sure about OP's intent, using the macro or using `const OPENSSL_STRING` directly yield the same result. – songyuanyao Feb 26 '21 at 15:14
3

@Dmitri The compilers are not required to do that, the behavior of clang is valid too. – songyuanyao Feb 26 '21 at 15:15

clang, gcc, and ignored qualifiers: who is right?

1 Answers1