[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rationale for closein
From: |
Rich Felker |
Subject: |
Re: rationale for closein |
Date: |
Tue, 19 Jun 2012 13:19:54 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: grantpt test, (continued)
- Message not available
- Message not available
- rationale for closein, Bruno Haible, 2012/06/18
- Re: rationale for closein, Rich Felker, 2012/06/18
- Re: rationale for closein, Bruno Haible, 2012/06/18
- Re: rationale for closein, Eric Blake, 2012/06/18
- Re: rationale for closein, Rich Felker, 2012/06/18
- Re: rationale for closein, Eric Blake, 2012/06/19
- Re: rationale for closein,
Rich Felker <=
- dlsym [was: rationale for closein], Eric Blake, 2012/06/19
- Re: rationale for closein, Paul Eggert, 2012/06/19