Path: utzoo!attcan!uunet!convex!killer!ames!nrl-cmf!cmcl2!phri!marob!daveh
From: daveh@marob.MASA.COM (Dave Hammond)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <372@marob.MASA.COM>
Date: 16 Nov 88 13:40:26 GMT
References: <54845@<1988Nov8> <225800090@uxe.cso.uiuc.edu>
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC  New York City
Lines: 27

In article <225800090@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>How about fixing this, and the scanf and strcpy problems as well,
>by a little outside-the-standard kludge? (Okay, I realize that every
>time I suggest something like this, somebody tries to roast me,
>but I am flameproof.) That is
>
>#pragma _MAX_STRING_LENGTH=256  /*or some other suitable number*/
>
>and the compiler would call special versions of gets, strcpy,
>and cohorts, that stopped at such a maximum. Now I am not sure whether
>the result of overrun would have to be a fatal error or whether
>it could just stop copying, but that would at least prevent 
>old bugs from biting too bad.

Sorry, but I fail to see where this (and a previous article suggesting
a 512 byte limit) helps the problem if the programmer uses a buffer
whos length is smaller than MAX_STRING_LENGTH.  The result is still
going to be an overflowed buffer, which is still going to be wrong.

The best solution is to have the programmer instruct the function as
to the *true* buffer length, and this can only be done with a function
which expects a length parameter (eg fgets()).

Dave Hammond
  UUCP: ...!uunet!masa.com!{marob,dsix2}!daveh
DOMAIN: daveh@marob.masa.com
----------------------------------------------------------------------------