Re: rationale for closein

[Eric Blake]

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?

By the way, if you think there is a bug in POSIX, please file a defect
report - it is in everyone's best interest to improve the standards,
instead of griping about them.

> 
> With that said, they have a good point, but it's also arguable that
> random parts of the program should not be using stdin/stdout.
> Conceptually, these streams "belong to" the main program flow, and
> except in really simple programs, they probably should not be used
> explicitly (either by name, or by calling stdio functions that
> explicitly use them) except in main or a similar function; other
> functions should just get a FILE * from the caller.

As long as the rest of the program just reads and writes, rather than
closes, the FILE* argument, then that is not a problem to your approach
of isolating the use of the standard streams to the main() part of the
program.

> 
>> 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
wording I come up with for the POSIX proposal will accommodate both the
existing __fpending implementations and the usage patterns that gnulib
has encouraged through its fpending module in order to provide valid
performance improvements, and to use those performance improvements as
justification why POSIX should consider the addition to the standard.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature