This is the mail archive of the mailing list for the newlib 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: Bug (?) in sprintf family?

The C standard makes no comment specifically on isatty() and friends,
even on how underlying supporting routines in general may be done.
These can be considered a requirement of the newlib implementation.
Refer to 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.)

-----Original Message-----
From: []
On Behalf Of Jonathan S. Shapiro
Sent: Monday, April 07, 2008 6:19 PM
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
> 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?


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