Re: [PATCH] Fix aliasing violation tst-rec-dlopen

[Pedro Alves <palves at redhat dot com>]

On 12/15/2015 03:04 PM, Mike Frysinger wrote:
> On 15 Dec 2015 15:02, Pedro Alves wrote:
>> On 12/15/2015 09:49 AM, Florian Weimer wrote:
>>> Some GCC versions warn about this.  It's a clear misuse (presumably to
>>> avoid writing down the funny function pointer type), so I propose to fix
>>> this, instead of assuming that GCC will do the right thing.
>>
>> It's actually the form suggested in the dlopen/dlsym man page's EXAMPLE section:
>>
>> ~~~
>>            /* Writing: cosine = (double (*)(double)) dlsym(handle, "cos");
>>               would seem more natural, but the C99 standard leaves
>>               casting from "void *" to a function pointer undefined.
>>               The assignment used below is the POSIX.1-2003 (Technical
>>               Corrigendum 1) workaround; see the Rationale for the
>>               POSIX specification of dlsym(). */
>>
>>            *(void **) (&cosine) = dlsym(handle, "cos");
>> ~~~
>>
>> http://linux.die.net/man/3/dlopen
> 
> that site is out of date.  the canonical source does not do this:
> http://man7.org/linux/man-pages/man3/dlopen.3.html#EXAMPLE
> -mike

Alright, it now says:

           /* According to the ISO C standard, casting between function
              pointers and 'void *', as done above, produces undefined results.
              POSIX.1-2003 and POSIX.1-2008 accepted this state of affairs and
              proposed the following workaround:

                  *(void **) (&cosine) = dlsym(handle, "cos");

              This (clumsy) cast conforms with the ISO C standard and will
              avoid any compiler warnings.

              The 2013 Technical Corrigendum to POSIX.1-2008 (a.k.a.
              POSIX.1-2013) improved matters by requiring that conforming
              implementations support casting 'void *' to a function pointer.
              Nevertheless, some compilers (e.g., gcc with the '-pedantic'
              option) may complain about the cast used in this program. */


In any case, it's clear that the intent here was to suppress the
warning.  But now GCC warns -- do we have a GCC regression?

(I'm not at all against the patch, TBC.)

Thanks,
Pedro Alves