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: [RFC] signal-safe fprintf?


On Thu, Mar 07, 2013 at 06:16:22PM +0530, Siddhesh Poyarekar wrote:
> On 7 March 2013 18:09, Rich Felker <dalias@aerifal.cx> wrote:
> > This is not a problem for the proposed usage, where the same FILE
> > would not be used in both places (one of the FILEs would be a
> > temp/dummy one created in snprintf). My only concern is whether
> > snprintf and dprintf add their dummy FILE to the global open file
> > list, which also involves locking. I seem to remember at least dprintf
> > doing this, but I may be mistaken..
> 
> Yes, just that even if we come up with such a function, it will only
> be useful for this specific use case and nothing else.  I'm not sure
> if that is useful enough.

Yes. I would imagine many people would just prefer to write to stderr
(and I agree that being able to do this from a signal handler would
have been really convenient very often).

However, we have dprintf(2), surely we could build on this part of the
API? Applications doing this stuff in signal handlers probably don't
care (or shouldn't care :) about the extra FILE* features.

				Petr "Pasky" Baudis


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