Deutsch   English   Français   Italiano  
<v4ltuj$3trj2$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Whaddaya think?
Date: Sun, 16 Jun 2024 07:41:38 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <v4ltuj$3trj2$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 16 Jun 2024 07:41:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="567efb17d94aca7729125b64ceeb67a7";
	logging-data="4124258"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191Mj+e1QYkzavKRX0kPw8J"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:8MQ+VgmMQFJmA8+1xPe+gJL1vgA=
In-Reply-To: <8734pd4g3s.fsf@nosuchdomain.example.com>
Bytes: 3194

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[])
{
    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.

Janis