Re: [PATCH 2/3] Introduce <pointer_guard.h>, extracted from <sysdep.h>

[Florian Weimer <fweimer@redhat.com>]

* DJ Delorie:

> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
>> +++ b/sysdeps/generic/pointer_guard.h
>> +#ifndef __ASSEMBLER__
>> +# define PTR_MANGLE(x) (void) (x)
>> +# define PTR_DEMANGLE(x) (void) (x)
>> +#endif
>
> These macros will always be called standalone, i.e.
>
>        inline uintptr_t demangle_ptr (uintptr_t x)
>  	{
>  	  PTR_DEMANGLE (x);
>  	  return x;
>  	}
>
> If that's the expectation, is there a reason why we need to even
> reference X at all?  Would an empty declaration be valid?  This should
> only affect volatile variables, but those would be referenced shortly
> after anyway.  Atomic boundaries aren't an issue as atomics are not used
> in the mangling compuation.
>
> I can see having a non-empty body as a valid way to validate the usage,
> but in that case something that actually validates it makes more sense
> by only accepting a LHS:
>
>> +# define PTR_MANGLE(x) (void) (&(x))
>
> (the non-generic usages should enforce this through their assignments)
>
> Also, is there any case where code could be corrupted by the lack of
> overall parens?  I.e. is this better:
>
>> +# define PTR_MANGLE(x) ((void) (x))

I copied this from the existing macros, e.g.

#define PTR_MANGLE(var) (void) (var)

in sysdeps/unix/sysv/linux/mips/mips64/sysdep.h.  I would rather not
tweak this and focus on replacing it with a generic version (that won't
protect setjmp/longjmp, but global variables).

Thanks,
Florian