This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus on MT-, AS- and AC-Safety docs.


On Tue, Dec 03, 2013 at 10:49:54AM -0500, Carlos O'Donell wrote:
> On 12/03/2013 10:39 AM, Andreas Schwab wrote:
> > "Carlos O'Donell" <carlos@redhat.com> writes:
> > 
> >> * Was it ever POSIX's intent to allow a signal handler to
> >>   modify the errno of the interrupted code sequence or was
> >>   that simply a consequence of being a signal handler and
> >>   modifying global state?
> > 
> > <http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.htm>:
> > 
> >     Note in particular that even the "safe" functions may modify errno; the
> >     signal-catching function, if not executing as an independent thread,
> >     should save and restore its value in order to avoid the possibility that
> >     delivery of a signal in between an error return from a function that
> >     sets errno and the subsequent examination of errno could result in the
> >     signal-catching function changing the value of errno.
> 
> It isn't clear from this statement, which I've read before, if it was
> ever intended that such error changing behaviour be allowed.
> 
> Did POSIX purposely allow signal handlers to change errno because they
> saw a use case that required it or was it simply a performance choice
> to allow signal handlers to avoid the penalty of saving and restoring
> the thread-local value?
>
A text above is recomendation of saving errno. How that implies that
returning errno by signal handler is allowed? 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]