Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!think.com!samsung!umich!dgsi!dbc
From: dbc@cimage.com (David Caswell)
Newsgroups: comp.unix.programmer
Subject: Re: Segmentation fault?
Message-ID: <1991Feb25.220330.12106@cimage.com>
Date: 25 Feb 91 22:03:30 GMT
References: <38192@netnews.upenn.edu> <945@caslon.cs.arizona.edu> <19099:Feb2505:49:2891@kramden.acf.nyu.edu>
Reply-To: dbc@dgsi.UUCP (David Caswell)
Organization: Cimage Corp, Ann Arbor, MI
Lines: 18

In article <19099:Feb2505:49:2891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
.> >  char line[BUFSIZ];		/* line of input */
.  [ ... ]
.> >  if (fgets(line, BUFSIZ, fp) == NULL)
.> Here is another, more subtle bug.  fgets will write up to BUFSIZ characters
.> (in this call) to line.  This is not including the final '\0' character.
.> The best thing to do is declare char line[BUFSIZ + 1], and all will be well.
.
.Uh, no. The fgets() interface was designed so that you could do things
.like fgets(line,sizeof(line),fp). Here it reads at most BUFSIZ - 1
.characters before the terminating null.

That is why it is so funny to see people do
while(fgets(str,1,fp)){
	...
}

for character-at-a-time input.


Brought to you by Super Global Mega Corp .com