Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!uwvax!topaz!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c
Subject: Re: mixing scanf and gets
Message-ID: <705@bentley.UUCP>
Date: Thu, 10-Apr-86 16:36:16 EST
Article-I.D.: bentley.705
Posted: Thu Apr 10 16:36:16 1986
Date-Received: Sat, 12-Apr-86 22:02:57 EST
References: <2476@brl-smoke.ARPA>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 21

In article <2476@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes:
>The problem with sscanf is that if your input only partially matches,
>there is no way to tell where [the next input character is].

Agreed.  I'm somewhat surprised this isn't listed under "BUGS".  Of
course, in many applications you don't care (just output "syntax error"
and toss the line away); and it may be feasible to re-parse the entire
line with a new format in any case.

>Fgets is worthless on binary data.  It returns its first argument, which I
>already know.  If a null is part of the data, how do you know where it
>stopped reading.  Well if you're lucky, there will be a newline in there
>and that's the end of it.  But if you're reading blocks of nulls, you're
>SOL.  I would like fgets to return the number of chars read.

Clearly fgets isn't intended for binary data.  (Who writes line-oriented
binary data??)  Probably fread is what you want.  However, I think you're
right that nchars is a more useful return value (though I'd be satisfied
with a boolean).

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint