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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
