Maybe the difference is in one kind taking a va_list
as an argument, and the other creating that argument 
list itself. IIRC, there are platforms that deal with  
the va_list in rather strange ways (believe you could 
end up actually copying the arguments - theoretically).

That /might/ make a difference if you're in a signal 
handler and your floating point context isn't saved.

Just my 1/2 cent worth of wild guessing....

- Thomas

> -----Ursprüngliche Nachricht-----
> Von: Sean Boudreau 
> Gesendet: 17 April 2008 16:55
> An: ostech-core_os
> Betreff: Re: vsnprintf / vsprintf .. doc question
> 
> 
> On Thu, Apr 17, 2008 at 10:43:46AM -0400, Stephane Boucher wrote:
> > On Thu, 2008-04-17 at 04:26 -0400, Jeevan Mathew wrote:
> > 
> > > For functions snprintf() and sprintf() there is NO such 
> restriction. 
> > > This seems rather strange to me. 
> > 
> > I think the restrictions should be the same, since 
> internally, both the
> > vsprintf and sprintf internally call _Printf.
> 
> But which is correct?  I can see printf() and friends
> that take a FILE * not being safe as they have to lock
> the FILE, but the 's' variants that operate on a buffer
> 'may' be safe (haven't rigorously verified it).
> 
> > 
> > See for yourself in the source repository for files:
> > 
> >   lib/c/stdio/sprintf.c
> >   lib/c/stdio/vsprintf.c
> > 
> > > Is the documentation really correct? And if it is, why this 
> > > restriction?
> > 
> > Well, as far as posix goes, you shouldn't use either in a signal
> > handler, look at the async-signal-safe functions at:
> > 
> > http://www.opengroup.org/onlinepubs/000095399/
> > 
> > 
> > 
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post6981
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post6984
> 

On Thu, 2008-04-17 at 10:54 -0400, Sean Boudreau wrote:
> On Thu, Apr 17, 2008 at 10:43:46AM -0400, Stephane Boucher wrote: 
> > On Thu, 2008-04-17 at 04:26 -0400, Jeevan Mathew wrote: 
> > 
> > > For functions snprintf() and sprintf() there is NO such
> restriction. 
> > > This seems rather strange to me. 
> > 
> > I think the restrictions should be the same, since internally, both
> the 
> > vsprintf and sprintf internally call _Printf.
> 
> But which is correct?  I can see printf() and friends 
> that take a FILE * not being safe as they have to lock 
> the FILE, but the 's' variants that operate on a buffer 
> 'may' be safe (haven't rigorously verified it).

The 's' ones may be safe, and probably are.  However, the only way to
know what the real answer is is to read the code.  FILE is the obvious
gotcha, but less obvious gotchas could have to do with temporary
buffers.  Nothing in posix says that sprintf needs to be re-entrant, so
in practice, one could decide to use a thread-local storage from within
printf (though, I don't believe this is the case with our libc)

Out of the top of my head, I recall seeing code that was doing floating
point divisions.  This could therefore theoretically cause a SIGFPE.
This may be the reason for the mentioned restriction, but if so, it
would apply to all of the *printf, since the conversion code is common
to all.  But, don't quote me on that, and the code in HEAD has changed
since last time I looked at it.

Alternatively, if you can ask the doc people to look at the history of
the doc, they might dig up a related PR which would explain this.

None of the *printf variants can be safe, since they may call malloc(),
which has
a BGL within.

Sean Boudreau wrote:
> On Thu, Apr 17, 2008 at 10:43:46AM -0400, Stephane Boucher wrote:
>  > On Thu, 2008-04-17 at 04:26 -0400, Jeevan Mathew wrote:
>  >
>  > > For functions snprintf() and sprintf() there is NO such restriction.
>  > > This seems rather strange to me.
>  >
>  > I think the restrictions should be the same, since internally, both the
>  > vsprintf and sprintf internally call _Printf.
> 
> But which is correct?  I can see printf() and friends
> that take a FILE * not being safe as they have to lock
> the FILE, but the 's' variants that operate on a buffer
> 'may' be safe (haven't rigorously verified it).
> 
>  >
>  > See for yourself in the source repository for files:
>  >
>  >   lib/c/stdio/sprintf.c
>  >   lib/c/stdio/vsprintf.c
>  >
>  > > Is the documentation really correct? And if it is, why this
>  > > restriction?
>  >
>  > Well, as far as posix goes, you shouldn't use either in a signal
>  > handler, look at the async-signal-safe functions at:
>  >
>  > http://www.opengroup.org/onlinepubs/000095399/
>  >
>  >
>  >
>  > _______________________________________________
>  > OSTech
>  > http://community.qnx.com/sf/go/post6981
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post6984
> 

-- 
cburgess@qnx.com

On Mon, 2008-04-21 at 02:18 -0400, Josef Rossmeier wrote:
> > However, *all* functions marked as signal safe are subject to the
> caveat that floating point are not safe (floating 
> > point registers are not saved before invoking the signal handler).
> 
> Does this really mean that using ANY floating point variables in a 
> signal handler is potentially unsafe?!

yes.