NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/c/13639

Internet Message Format | 1992-09-14 | 2.9 KB

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!wirzeniu
From: [e-mail] (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: dropping a n from a f
Message-ID: <[e-mail]>
Date: 14 Sep 92 15:00:48 GMT
References: <199214.4396.25154@dosgate>
Distribution: comp
Organization: University of Helsinki
Lines: 58

"alan popow" <[e-mail]> answers a query about reading lines
from text lines without reading the line-terminating newline with a
suggestion to use the following code:

>     FILE *fp1, *fp2;
>     char *item = "";
>     int i = 0;
>
>     while(((item[i] = fgetc(fp1)) != '\n') && (i < 20))
>         i++;
>
>     item[i] = '\0';

While I realize that this most probably was only meant as a guideline (I
try to point out when I post code like this, myself), but being in a
particularly nitpicky mood, I want to point out some shortcomings of the
code.  This is not intended as a flame, only as constructive criticism.
(I consider any code posted on the Net to be a valid target for such
criticism, and of course all of my articles, especially nitpicking ones
like this.)

The above code tries to accomplish the same thing as the following:

    fgets(item, 20, fp1)
    ...and then get rid of the newline at the end...

However, it does not quite succeed, for two reasons:

1.  The hopefully familiar problem of storing the result of
    fgetc/getc/getchar into a char, not an int, which leads to problems
    with distinguishing EOF from a valid value for a char.  The range of
    the values that fgetc/getc/getchar return is greater than the range
    of values which a char variable can take, so storing the result into
    a char looses information.

2.  Not checking for EOF.  The program will store garbage values into
    the string if it tries to read past the end of the file.  Please
    remember to check for error codes whenever you can (there a some
    valid places where it is often not necessary to check for error
    codes, but they are rather rare and can be the result of bad
    interface design, e.g.  the return value of printf).  As soon as one
    starts believing that "it can't happen to me", it will.

Also, since the initialization of the `item' variable looks suspect, I
think I should warn about storage allocation here: there is no code
shown that will allocate memory to hold the string itself, only the
pointer.  Unless you explicitly allocate some storage and set `item' to
point at that storage, you will overwrite things in memory that you
shouldn't overwrite (namely, in this case, the string literal; in the
more usual case, with no initialization, random places in memory will be
overwritten).

(The initialization seems suspect since it is unnecessary -- there is no
need to make `item' point to a string literal and later make it point to
some other place to which you can store the strings that you read.)

--
[e-mail]