Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Whaddaya think?
Date: Sun, 16 Jun 2024 10:44:25 +0300
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <20240616104425.0000548d@yahoo.com>
References: <666ded36$0$958$882e4bbb@reader.netnews.com>
	<20240616015649.000051a0@yahoo.com>
	<v4lm16$3s87h$4@dont-email.me>
	<v4lmso$3sl7n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 16 Jun 2024 09:44:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="803ce1cb02e96f5cc52a73edab1c8c37";
	logging-data="4157539"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Dm62uBXnywl8YzE4cCUDuJLwANqL4N2k="
Cancel-Lock: sha1:3ejZb1G/csiF7q4U8mbFyfLUmoM=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2382

On Sun, 16 Jun 2024 05:41:12 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 16.06.2024 05:26, Lawrence D'Oliveiro wrote:
> > On Sun, 16 Jun 2024 01:56:49 +0300, Michael S wrote:
> >   
> >> If you want to preserve you sanity, never use fscanf().  
> > 
> > Quoth the man page <https://manpages.debian.org/3/scanf.3.en.html>:
> > 
> >     It is very difficult to use these functions correctly, and it is
> >     preferable to read entire lines with fgets(3) or getline(3) and
> >     parse them later with sscanf(3) or more specialized functions
> > such as strtol(3).  
> 
> This would be also my first impulse, but you'd have to know
> _in advance_ how long the data stream would be; the function
> requires an existing buffer.

Define formats with sensible maximal line length (512 sounds about
right) and refuse any input that has longer lines.

> So you'd anyway need a stepwise
> input. On the plus side there's maybe a better performance
> to read large buffer junks and compose them on demand? But
> a problem is the potential cut of the string of a number; it
> requires additional clumsy handling. So it might anyway be
> better (i.e. much more convenient) to use fscanf() ?
> 

No, the behaviour of fsacnf() is too non-intuitive.

> Janis
>