Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: sprintf(3s) query
Message-ID: <754@auspex.UUCP>
Date: 19 Dec 88 21:42:00 GMT
References: <1102@entropy.ms.washington.edu> <8131@ihlpl.ATT.COM> <865@quintus.UUCP> <9181@smoke.BRL.MIL> <878@quintus.UUCP> <9205@smoke.BRL.MIL> <887@quintus.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>I think the following three points are uncontroversial:
>(1) The (4.2BSD, S5R2, S5R3, Ultrix, SunOS) manual pages for printf(3s)
>    do not say what any of the conditions which can cause an error return
>    are.  (I haven't seen the 4.3BSD manual page.)

I checked the 4.3-tahoe manual, and a quick look reveals no indication
of what the conditions that cause an error return are; I don't have the
4.3BSD page handy, but I don't remember it containing any such
indication.

>(2) There are a lot of errors which sprintf() either converts quietly to
>    something plausible or dumps core with, not least buffer overflow.

This doesn't have to be true of "sprintf", although for most existing
implementations this is true (buffer overflow is harder to catch in most
C implementations than, say, some format-string syntax errors are).

>(3) A portable program cannot rely on sprintf() catching any error at
>    all, and thus had better do its own argument validation in any
>    case.

This is true.

>It would be interesting to hear from someone who has UNIX sources what
>the reported errors are.  

My quick check of the S5R3 source indicates that "printf" and "fprintf". 
return EOF only if "ferror" on the stream being written to indicates an
error, or if "_doprnt" returns EOF, and "sprintf" does so only if
"_doprnt" returns EOF.  "_doprnt", and other I/O functions, set the I/O
error flag on a stream only if a "write" call returns an error
indication.  Since "sprintf" isn't supposed to write anything, this
means it should never return EOF in that implementation.