Re: rationale for closein

[Rich Felker]

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