dlsym [was: rationale for closein]

2012-06-19 Thread Eric Blake
On 06/19/2012 11:19 AM, Rich Felker wrote: >> 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 wit

Re: rationale for closein

2012-06-19 Thread 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 seriou

Re: rationale for closein

2012-06-19 Thread Paul Eggert
On 06/18/2012 08:30 PM, Rich Felker wrote: > after a > successful flush, I consider it the operating system's data loss, not > the application's, if the data fails to end up on permanent storage. Many operating systems behave that way, alas. This is for performance reasons. NFS is a classic exam

Re: rationale for closein

2012-06-19 Thread 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

Re: rationale for closein

2012-06-18 Thread Rich Felker
On Mon, Jun 18, 2012 at 08:17:25PM -0600, Eric Blake wrote: > On 06/18/2012 06:01 PM, Rich Felker wrote: > > > > > If the "closeout" approach works best for coreutils, that's the > > business of the coreutils' maintainers, not my business. However, as I > > discussed on the musl list, I think it'

Re: rationale for closein

2012-06-18 Thread Eric Blake
On 06/18/2012 06:01 PM, Rich Felker wrote: > > If the "closeout" approach works best for coreutils, that's the > business of the coreutils' maintainers, not my business. However, as I > discussed on the musl list, I think it's bad design, and I would > highly recommend other projects not follow i

Re: rationale for closein

2012-06-18 Thread Bruno Haible
Rich Felker wrote about 'closeout': > ... Conceptually, you're > turning something that's a local variable ... into a global, and > thereby losing the _local_ > information of whether it was used in the first place, which has to be > recovered with the non-portable __fpending. Correct. We do this

Re: rationale for closein

2012-06-18 Thread Rich Felker
On Tue, Jun 19, 2012 at 01:28:24AM +0200, Bruno Haible wrote: > Rich Felker wrote in > : > > I've already discussed on this list why using an atexit function for > > closing stdin or stdout is the heart of the problem and the source of > > all the co

rationale for closein

2012-06-18 Thread Bruno Haible
Rich Felker wrote in : > I've already discussed on this list why using an atexit function for > closing stdin or stdout is the heart of the problem and the source of > all the complexity. If the main program just closed the stream at the > natural po