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