Post by firstname.lastname@example.org Post by Keith Thompson
Are you suggesting that
can behave differently? If not, what are you talking about?
They could potentially do so.
Sure, they could. However:
"The fputs function writes the string pointed to by *s* to the stream pointed to by *stream*. The terminating null character is not written." (220.127.116.11p2)
"The puts function writes the string pointed to by *s* to the stream pointed to by *stdout*, and appends a new-line character to the output. The terminating null character is not written." (18.104.22.168p2)
In the call fputs(s, stdout), "the stream pointed to by *stream*" IS "the stream pointed to by *stdout*". With that substitution, the two descriptions become identical except the part about the newline character.
Therefore, any implementation of C that produced different observable behavior for puts(s) and fputs(s, stdout) would be non-conforming. Do you know of any implementation that is non-conforming in that fashion?
Post by email@example.com
... MS-DOS systems have low-level and high-level
ways of doing console I/O; the high-level I/O supports indirection but on
older systems was dog slow. Console I/O using the lower-level approaches
could be more than twice as fast as using the high-level approaches. Since
writing a screen of text through high-level DOS calls could take several
seconds, that would be a useful speedup.
The MS-DOS compilers I've used made "printf" go through stdout and added
new functions like "cprintf" to output things more quickly, but I would
not be surprised if some compilers used the faster routines by default
rather than sending everything through stdout.
I presume that cprintf() can avoid sending everything through stdout, because it is defined as writing to the console, regardless of what stream stdout refers to. Does it interact properly with printf()? For instance, if stdout points to a stream associated with the console, and if the side effects of a particular call to cprintf() are required by the C standard to be sequenced after the side-effects of a particular printf() call, does that actually happen? Since, for printf(), those side effects involve the flushing of the buffer associated with stdout, I don't see how they could be properly sequenced if cprintf() fails to interact with the data structures associated with that buffer. This would be permissible, since there's no way to link in cprintf() that doesn't render the behavior of the code undefined - but it would be rather annoying.
However, printf(), puts(), and fputs(..., stdout) are all defined as writing to whichever stream stdout points at, so none of those functions has the option of not "sending everything through stdout". If a program uses freopen() to associate stdout with a different stream, then printf(), puts(), and fputs(..., stdout) are all required to to send their output to that same different stream.
In any event, the speed with which something happens is constrained by the C standard. Differences in the speed do not count as differences in observable behavior. If that's the only way that puts(s) and fputs(s, stdout) differ, that would not, in itself, render such an implementation non-conforming.
However, if puts() could somehow always send it's output to whichever stream stdout refers to, even if reopened, while gaining a speed advantage by somehow doing so without "sending everything through stdout", then what prevents fputs(..., stream) from taking that same approach whenever stream==stdout?