Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Whaddaya think?
Date: Sat, 15 Jun 2024 22:49:11 -0700
Organization: None to speak of
Lines: 64
Message-ID: <87y17530a0.fsf@nosuchdomain.example.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> <v4lr0m$3tbpj$1@dont-email.me>
	<8734pd4g3s.fsf@nosuchdomain.example.com>
	<v4ltuj$3trj2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 16 Jun 2024 07:49:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2de609396a989ebb89e0552bebaeb129";
	logging-data="4116612"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19dilP87EF64atvRgkQ38XD"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:c3HcTB1D9OGXzv3ah4aO3DZstGY=
	sha1:52gk9GJtusGlVhjzGRh9jq7e/R0=
Bytes: 3536

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 16.06.2024 07:21, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 16.06.2024 05:41, Janis Papanagnou 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. So you'd anyway need a stepwise
>>>> input. [...]
>>>
>>> Would it be sensible to have a malloc()'ed buffer used for the first
>>> fgets() and then subsequent fgets() work on the realloc()'ed part? I
>>> suppose the previously set data in the malloc area would be retained
>>> so that there's no re-composition of cut numbers necessary?
>> 
>> Sure.  "The contents of the new object shall be the same as that of the
>> old object prior to deallocation, up to the lesser of the new and old
>> sizes."
>> 
>> Keep in mind that you can't call realloc() on a non-null pointer that
>> wasn't allocated by an allocation function.
>
> Thanks. - I've just tried it with this ad hoc test code
>
> #include <stdlib.h>
> #include <stdio.h>
>
> void main (int argc, char * argv[])

*Ahem* -- int main.

> {
>     int chunk = 10;
>     int bufsize = chunk+1;
>     char * buf = malloc(bufsize);
>     char * anchor = buf;
>     while (fgets(buf, chunk+1, stdin) != NULL)
>         if (realloc(anchor, bufsize += chunk) != NULL)
>             buf += chunk;
>     puts(anchor);
> }
>
> I wonder whether it can be simplified by making malloc() obsolete
> and using realloc() in a redesigned loop.

Yes.

"If ptr is a null pointer, the realloc function behaves like the malloc
function for the specified size."

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */