Bug (?) in sprintf family?

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

"Jonathan S. Shapiro" wrote:

> 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.

The snprintf family of functions are all implemented in
terms of
_vfprintf_r, by constructing a pseudo FILE * to represent
the string
buffer whose _flags indicate that it's really a string
buffer (__SSTR)
and not a file stream.  This allows for there to be one
implementation
of the actual formatted output code instead of having to
duplicate it,
so the coupling is deliberate.

I would think that things like calls to isatty() would be
guarded by
!(_flags & __SSTR) but in any case if you just stub out
everything
needed to link and the string output ones ought to still
work.

Brian

On Mon, 2008-04-07 at 13:52 -0700, Brian Dessent wrote:
> The snprintf family of functions are all implemented in
terms of
> _vfprintf_r, by constructing a pseudo FILE * to
represent the string
> buffer whose _flags indicate that it's really a string
buffer (__SSTR)...
>
> I would think that things like calls to isatty() would
be guarded by
> !(_flags & __SSTR)...

This is pretty much what I thought was going on. The problem
is not that
isatty() is being called. The problem is that it must be
resolved at
link time.

What I'm trying to ask is: should sprintf() and friends have
any **link
time** dependency on isatty() and friends? Does the C
library standard
state any position on this?


shap

The C standard makes no comment specifically on isatty() and
friends,
nor
even on how underlying supporting routines in general may be
done.
 
These can be considered a requirement of the newlib
implementation.
Refer to http://
sourceware.org/newlib/libc.html#SEC195 for comments
on what needs to be done, including sample stubs for those
things which
do require link-time resolution.  (The list is potentially
overstated,
as many of them are only required as you link particular
library
functions, of course.)  This is regular practice for
libraries, and
would likely not be considered a bug by most.  (A nice
enhancement
would be if the stubs mentioned in the documentation were
provided in
a stubs sub-directory for use by minimal implementations. 
For your
specific case, isatty.c in the libgloss subdirectory has
what the
aforementioned URL recommends.)
 
Craig  

-----Original Message-----
From: newlib-ownersourceware.org [mailto:newlib-ownersourceware.org]
On Behalf Of Jonathan S. Shapiro
Sent: Monday, April 07, 2008 6:19 PM
To: newlibsourceware.org
Subject: Re: Bug (?) in sprintf family?

On Mon, 2008-04-07 at 13:52 -0700, Brian Dessent wrote:
> The snprintf family of functions are all implemented in
terms of
> _vfprintf_r, by constructing a pseudo FILE * to
represent the string
> buffer whose _flags indicate that it's really a string
buffer
(__SSTR)...
>
> I would think that things like calls to isatty() would
be guarded by
> !(_flags & __SSTR)...

This is pretty much what I thought was going on. The problem
is not that
isatty() is being called. The problem is that it must be
resolved at
link time.

What I'm trying to ask is: should sprintf() and friends have
any **link
time** dependency on isatty() and friends? Does the C
library standard
state any position on this?


shap

"Jonathan S. Shapiro" wrote:

> What I'm trying to ask is: should sprintf() and friends
have any **link
> time** dependency on isatty() and friends? Does the C
library standard
> state any position on this?

Right, I think it will be hard or impossible to remove the
link-time
dependency, but the stubs should be dead code if no file
streams are
ever actually used.

Regarding the standard, I don't know for sure but I would
guess this is
too much of a platform/implementation specific issue.

"Howland Craig D (Craig)" wrote:

> (A nice enhancement
> would be if the stubs mentioned in the documentation
were provided in
> a stubs sub-directory for use by minimal
implementations.  For your
> specific case, isatty.c in the libgloss subdirectory
has what the
> aforementioned URL recommends.)

I think that is the whole point of libgloss, quoting
<

On Mon, 2008-04-07 at 16:16 -0700, Brian Dessent wrote:
> "Howland Craig D (Craig)" wrote:
> 
> > (A nice enhancement
> > would be if the stubs mentioned in the
documentation were provided in
> > a stubs sub-directory for use by minimal
implementations.  For your
> > specific case, isatty.c in the libgloss
subdirectory has what the
> > aforementioned URL recommends.)
> 
> I think that is the whole point of libgloss, quoting
> <

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
>
>   

On Mon, 2008-04-07 at 19:43 -0400, Jeff Johnston wrote:
> I'm looking at this.  I have one patch for vfprintf.c,
but there may be 
> other patches required.

It would certainly be an improvement if sprintf did not rely
on file
ops, but if the C library standard does not require this
separation of
concerns, I don't want our tree to rely on it.

shap

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
>>
>>   
>

On Wed, 2008-04-09 at 15:36 -0400, Jeff Johnston wrote:
> 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:

Since the separation of sprintf/scanf from the I/O stuff
isn't part of
the C library specification, this patch doesn't really do me
any good.
In fact, I'ld prefer that it not be applied. Had this patch
already been
applied when I started, it would have had the effect of
obscuring a bug.

shap