Path: utzoo!attcan!uunet!husc6!cmcl2!phri!marob!daveh
From: daveh@marob.MASA.COM (Dave Hammond)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <365@marob.MASA.COM>
Date: 11 Nov 88 15:24:03 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <32301@oliveb.olivetti.com>
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC  New York City
Lines: 32

In article <32301@oliveb.olivetti.com> chase@Ozona.UUCP (David Chase) writes:
>You should also consider retiring certain features of 'scanf' and
>'fscanf'.  A call along the lines of
>
>    scanf("%s", junk);
>
>is perfectly able to scribble past the end of 'junk'.  I'm not sure if
>there are other holes like this built in to the standard i/o library;
>it wouldn't hurt to check.  (I've never been a real fan of 'scanf',
>but it does seem marginally more useful and harder to replace than
>'gets').

Carrying this line of thought foreward, it would seem that Mr. Chase
advocates retiring any library call which requires that the programmer
take responsibility for providing enough buffer space to handle the
data resulting from the call in question.

IMHO, if the programmer is aware that the library call does not know
about buffer length (which is obvious when no length parameter is passed
to the call), then it is the programmers responsibility to ensure that
(a) the buffer is of an appropriate length for his/her application, or
(b) if an appropriate length can not be determined, the call should *not*
be used.

[the unnecessary overhead of calling scanf("%s") instead of fgets()
 or a getc() loop might also be pointed out -- but I suspect the example
 was nothing more than that]

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