Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: gets(3) nonsense
Message-ID: <739@quintus.UUCP>
Date: 24 Nov 88 02:14:09 GMT
References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <14447@mimsy.UUCP> <1643@solo11.cs.vu.nl> <1403@unisoft.UUCP> <644@scotty.UUCP> <1251@vsedev.VSE.COM>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 24

In article <1251@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes:
>In article <644@scotty.UUCP> jwr@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()...