Re: sprintf question

[Anders Lindgren <ali at df dot lth dot se>]

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