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