Bug (?) in sprintf family?

[Jeff Johnston]

Please try the attached patch.  It disconnects the sprintf and sscanf 
family of functions from bringing in all the I/O stuff.  This is 
especially useful since tzset drags in sscanf.

If I missed something, let me know.

-- Jeff J.

Jeff Johnston wrote:
> I'm looking at this.  I have one patch for vfprintf.c, but there may 
> be other patches required.
>
> -- Jeff J.
>
> Jonathan S. Shapiro wrote:
>> I am not sure whether or not this is a bug; my goal is to find out.
>>
>> I have a call to vsnprintf. This is failing because isatty() is not yet
>> defined by our libc port.  The call to isatty() is being made from
>> within __smakebuf_r. There are also references to the reentrant versions
>> of close, read, write, sbrk, fstat, and lseek.
>>
>> Now I do understand that all of these are required to do anything
>> significant with stdio, but it is somewhat surprising that they are
>> required for sprintf, which really doesn't need to touch the
>> file-oriented logic at all.
>>
>> Is the implementation of sprintf deficient, or does the libc standard
>> not require any independence between sprintf and the file system?
>>
>> I can either stub out the missing routines or supply a replacement for
>> vsnprintf in our coyotos-specific library, but before I do I would like
>> to understand whether this should be viewed as a newlib bug.
>>
>> Heck, vsnprintf doesn't have a FILE* to work with, so there isn't any
>> fd, so I'm not entirely sure what these routines could possibly be
>> getting called *on* in this case. The program makes no other use of
>> stdio.
>>
>>
>> shap
>>
>>   
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stringio.patch
Type: text/x-patch
Size: 24437 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20080409/d07fee01/attachment.bin>