Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!uflorida!ukma!cwjcc!tut.cis.ohio-state.edu!osu-cis!att!ihlpb!gregg
From: gregg@ihlpb.ATT.COM (Wonderly)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <9054@ihlpb.ATT.COM>
Date: 10 Nov 88 22:29:30 GMT
References: <8847@smoke.BRL.MIL>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 26

From article <8847@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ):
> In article <1031@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
>>This may be a naive question, or perhaps I haven't followed the right
>>stories, but what is the problem with using gets versus fgets?
> 
> If you don't know for sure that the input line will fit the buffer
> you've allocated for it, gets() can overrun the buffer (with random
> consequences).  However, if your program can be sure that the line
> will fit, there is nothing wrong with using gets().

I believe that the right thing to do is to use a new function called
nlfgets (str, size, fp), that does exactly as gets(3).  The biggest
concern that most people have about moving from gets to fgets is the
added hassle of doing a 

	if ((t = strchr (buf, '\n')) != NULL)
		*t = 0;

This seems to be a lot of work when you may be processing thousands of
lines of code.  I have written this exact function many times just to
have the benefit of no strchr() call.


-- 
It isn't the DREAM that NASA's missing...  DOMAIN: gregg@ihlpb.att.com
It's a direction!                          UUCP:   att!ihlpb!gregg