This is the mail archive of the newlib@sourceware.org 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: sprintf question


On Wed, 28 Feb 2007, Robin Getz wrote:

[cut]

It seems that sprintf, in libc/stdio/sprintf.c calls _vfprintf_r, which needs
<<close>>, <<fstat>>, <<isatty>>, <<lseek>>, <<read>>, <<sbrk>>, <<write>>.

I thought it strange, that operations purely on a buffer, would require
supporting OS file subroutines. I can understand why these are necessary for
printf, fprintf, but why sprintf?

Can someone explain?

There are a bunch of *printf variants in stdlib, so it makes sense to have a single function doing all the (messy!) work and make the others simple wrappers around that function.


Virtually all stdio implementations I have come across do this the same way[0]: They construct a dummy stdio FILE object with a special flag indicating that it's really just a buffer, and then call vfprintf to do the job. This is a plain dumb convention in many embedded systems, as you have just noticed...

ARM Ltd's libc has a [v]snprintf implementation that doesn't pull in the rest of the world. It also consumes a heck of a lot less stack than "the usual" printf implementations. Ideally, I would like to have all the other printf-variants on top of a stack-friendly vsnprintf instead of the other way around, but seeing as I haven't submitted any such patches myself I shouldn't complain...

[0]   Probably because they are all based on the same BSD code,
    which wasn't written for embedded systems.

/ali:)


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