Re: Clang-6 and GNUisms.

On 12 Mar 2018, at 00:56, Ian FREISLICH <ian.freislich_at_capeaugusta.com> wrote:
> 
> There's been some fallout in ports land since clang-6 around null
> pointer arithmetic and casts.  I cannot think of a good reason for doing
> the following but then I've not dabbled in the arcane much:
> 
> # define __INT_TO_PTR(P) ((P) + (char *) 0)

The idea of this construct is to store integers in pointers, and vice
versa.  This could also be done with unions, but those have their own
portability issues.

However, arithmetic on a null pointer is undefined according to the C
and C++ standards, though this particular use case is a GNU extension.

It would be safer and more portable to use intptr_t (or a custom integer
type that is exactly as large as a pointer), then cast the pointer to
that type, and vice versa.

E.g.:

#define __INT_TO_PTR(i) ((char *)(intptr_t)(i))
#define __PTR_TO_INT(p) ((intptr_t)(char *)(p))

That said, -Wno-null-pointer-arithmetic can of course be used to
suppress the warnings, but unfortunately this not only applies to the
GNU extension, but also to real undefined behavior.


> So far I've encountered these in lang/v8 and devel/avr-gcc.  I know it
> just generates warnings, but GNUisms and -Werror abound.  Adding
> -Wno-null-pointer-arithmetic and -Wno-vexing-parse to CFLAGS/CXXFLAGS
> provides some relief but V8 still fails:
> 
> /usr/ports/lang/v8/work/v8-3.18.5/out/native/obj.target/v8_base.x64/src/type-info.o../src/stub-cache.cc:1477:33:
> error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed
>       : GetCodeWithFlags(flags, reinterpret_cast<char*>(NULL));
> 
>                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this case, the casting is unnecessary, and can simply be removed.

The "vexing parse" warning is caused by unnecessary (and confusing)
parentheses, which can also be removed.

See the attached patch, which fixes both issues, and suppresses the
null pointer arithmetic warnings.


> I haven't got avr-gcc to compile yet.

No idea about this, is it very different from regular gcc's?  As those
all compile fine now.

-Dimitry