On Tue, Jun 19, 2012 at 06:11:35AM -0600, Eric Blake wrote: > On 06/18/2012 09:30 PM, Rich Felker wrote: > > >> > >> And that's where I disagree - the POSIX folks _specifically_ recommend > >> the closeout approach of an atexit() handler: > > > > Yes, they also recommend invoking extremely serious UB (aliasing > > violation, which GCC _will_ miscompile) when using dlsym to obtain a > > function pointer... > > POSIX is at liberty to define semantics that are not guaranteed by > C99/C11, and dlsym() is one of those situations where POSIX has indeed > required more from the compiler (including that function pointers can be > cast to void* and back again without ill effects). As written in > http://austingroupbugs.net/view.php?id=74, > > Note that conversion from a void * pointer to a function pointer > as in: > > fptr = (int (*)(int))dlsym(handle, "my_function"); > > is not defined by the ISO C Standard. This standard requires > this conversion to work correctly on conforming implementations. > > Do you have proof that gcc miscompiles dlsym() when used in the manner > recommended by the latest wording? And if so, have you filed it as a > gcc bug?
I'm not talking about this; this is actually the correct way to do it. But the POSIX documentation for dlsym contains an example: *(void **)(&fptr) = dlsym(handle, "my_function"); which violates the aliasing rules, and which a compiler cannot support without throwing away aliasing-related optimizations altogether. > >> But our argument is that __fpending (well, 'fpending') _should_ be > >> portable, and I am in the process of proposing it for standardization in > >> the next version of POSIX because it is so useful. > > > > Are you proposing that it be called __fpending or fpending? > > The POSIX proposal will be for a function named 'fpending'. But until > it is accepted as part of the standard, my recommendation would be that > libc writers implement it as '__fpending', so as to not pollute > namespace, and so that any minor differences between various libc > initial implementations and the final agreed-on POSIX requirements can > be dealt with as part of adding 'fpending' later. My hope is that the Sounds very reasonable/clean. Rich