gets(3) nonsense

Richard A. O'Keefe ok at quintus.uucp
Thu Nov 24 12:14:09 AEST 1988


In article <1251 at vsedev.VSE.COM> logan at vsedev.VSE.COM (James Logan III) writes:
>In article <644 at scotty.UUCP> jwr at scotty.UUCP (Dier Retlaw Semaj) writes:
>>What about sprintf() & fprintf()?
>>The user does not have *complete control* over these functions.
>True, sprintf() could write beyond the end of the string passed
>as its first parameter.  But I don't see what damage fprintf()
>would do, unless it does not check its internal buffer boundaries
>as it expands the format string.

Oddly enough, there used to be versions of *printf() around that
_could_ corrupt the stack in a gets()-like way.  If I remember correctly,
the magic number was something like 127 characters of plain text.  That
is, if you had too much text before you came to the next %, your stack
could be damaged.  That version of _doprint copied the plain text to the
stack, and wrote it from there.  Now, this _was_ documented in the manual,
but it was very easy to overlook that.

Speaking of which, I just noticed that the man page on the system I am
using now says
	BUGS
	    Very wide fields (>128 characters) fail.
I do not know whether this is the same bug.

And people wonder why I wrote my own printf()...



More information about the Comp.lang.c mailing list