1

my understanding is that most implementations of printf rely on something like

vsnprintf( _acBuffer[0], sizeof( _acBuffer[0] ), pcFormat, *ptArgList );

to actually handle the formatting and then they output them to the stream via puts.

Are there any implementation that minimize the size of _acBuffer[0] required while maintaining the ability to print all string?

Obviously something like :

printf("%s", pcReallyLongString);

would be a problem.

Your thoughts are much appreciated!

abelenky
  • 63,815
  • 23
  • 109
  • 159
Pablitorun
  • 1,035
  • 1
  • 8
  • 18
  • 5
    Where do you get your understanding from? It seems completely wrong based on my experience. – abelenky Jul 06 '12 at 18:12
  • 3
    SUGGESTION: try it, and see where (or if!) you max out `printf("%s", pcReallyLongString);` PS: "sizeof( _acBuffer[0] )" makes no sense ;) – paulsm4 Jul 06 '12 at 18:16
  • mostly from here http://stackoverflow.com/questions/4867229/code-for-printf-function-in-c and our internal implementation. If you can provide insight into my misunderstanding I would appreciate it. – Pablitorun Jul 06 '12 at 18:22
  • @paulsm4 I know it won't work in the particular implementation I am working with. I guess I need to poke around and see what other implmenetations do. Thanks – Pablitorun Jul 06 '12 at 18:23
  • wait my bad....the answer I linked to is passing in stdout, my bad. thanks guys. – Pablitorun Jul 06 '12 at 18:31
  • 1
    @Pablitorun: there's no mention of `vsnprintf` whatsoever in the link you provided. Rather, the glibc implementation implements the formating in `vfprintf`. – jpalecek Jul 06 '12 at 18:32
  • @jpalecek yes my head is hanging in shame. My bad ladies and gentleman. I wish I could give you all karma or points or whatever they are called on here. – Pablitorun Jul 06 '12 at 18:37
  • 1
    Why the down and close votes? This is a good question even if it's based on a misunderstanding of how things actually work in it. – Michael Burr Jul 06 '12 at 20:12
  • @MichaelBurr: I agree completely. +1 to compensate. This is a very good question. – R.. GitHub STOP HELPING ICE Jul 06 '12 at 21:36
  • As for **why** it's a good question, it shows that OP was actually thinking about resources as finite and failure as a possibility. This sort of thinking is rare and precious in programmers. – R.. GitHub STOP HELPING ICE Jul 07 '12 at 01:01

2 Answers2

4

Your understanding is just wrong. I've never seen or heard of a printf implementation that works by first formatting the entire output to a temporary string buffer. Usually printf is done the other way around: the fundamental building block is vfprintf and vsnprintf is a wrapper for that which creates a fake FILE whose buffer is the destination string.

Edit: Some popular (e.g. glibc) implementations do make some use of unboundedly-large intermediate buffers for certain formats, especially wide character conversions, and will fail unpredictably when they cannot allocate sufficient memory for the buffer. This is purely a low-quality-implementation issue, however; there's no fundamental reason any of the printf functions should require any more than a small constant amount of working space, regardless of what they're printing.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
2

I'd say that the whole point of fprintf (or printf) specification being the way it it is to allow a "bufferless" one-pass implementation of this function. I.e. it converts the data sequentially piece by piece (if it requires conversion), immediately sends it to the output and forgets about it for good. The function can use an intermediate buffer for numeric data conversion, but this is a temporary buffer of fixed and insignificant compile-time size.

Unless I'm missing something, a properly implemented fprintf function should impose absolutely no limitations on how long the resultant string is. Your hypothetical implementation through vsnprintf would violate that principle.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • Each `%` specifier is one conversion. So the standard allows implementations to use a fixed-size buffer for each of these conversions, but not for the entire `printf` call. – R.. GitHub STOP HELPING ICE Jul 06 '12 at 22:27
  • @R..: You are right. The intent was, obviously, to refer to a conversion performed by a *single format specifier*, not to the entire invocation of `fprintf`. Edited the answer. – AnT stands with Russia Jul 06 '12 at 22:42