Re: Whaddaya think?

On 16.06.2024 13:31, Michael S wrote:

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

On 16.06.2024 11:38, Michael S wrote:

 

>
Again; which ones?
>
Janis
>

[...] 

>
>

 
The main misconceptions are about what is returned by fgets() and by
realloc().
fgets() returns its first argument in all cases except EOF or FS read
error. That includes the case when the buffer is too short to
accommodate full input line.

   fgets() return s on success, and NULL on error or when end
           of file occurs while no characters have been read.

I am interested in the success case, thus "fgets() != NULL".
The buffer size is controlled by the second function parameter.

 
With realloc() there are two issues:
1. It can sometimes return its first argument, but does not have to. In
scenario like yours it will return a different pointer quite soon.
2. When realloc() returns NULL, it does not de-allocate its first
argument.
 
The second case, of course, is not important in practice, because in
practice you're very unlikely to see realloc() returning NULL, and if
nevertheless it did happen, you program is unlikely to survive and give
meaningful result anyway. Still, here on c.l.c we like to pretend that
we can meaningfully handle allocation failures.

You may provide "correct" code (if you think mine is wrong). Or just
inspect how it behaves; here's the output after two printf's added:

$ printf "123 456 789 101112 77 88 99 101 999" | realloc
+++>123 456 78<+++
===>123 456 78<===
+++>9 101112 7<+++
===>123 456 789 101112 7<===
+++>7 88 99 10<+++
===>123 456 789 101112 77 88 99 10<===
+++>1 999<+++
===>123 456 789 101112 77 88 99 101 999<===
123 456 789 101112 77 88 99 101 999

The +++data+++ is the chunk read, and the ===data=== is the overall
buffer content, and the final line again the result (as before, with
the added newline as documented for puts()).

Even though my code is just an "ad hoc test code" to demonstrate the
procedure I outlined - and as such test code certainly lacking quite
some error handling and much more - it does exactly what I intended it
to do, and what I've implemented according to what I read in the man
pages. I cannot see any "misconception", it does what was _intended_.

There's indeed one point that I _deliberately_ ignored for the test
code; actually the point you mentioned as "not important in practice".

Again: You may provide "correct" code (if you think mine is "wrong"),
or "better" code, usable for production instead of a test code.

But your tone and statements were (as observed so often) inadequate;
I quote from your post that started the subthread:
"However it looks unlikely that it does what you meant for it to do."

It does exactly what I meant to do (as you can see in the logs above).

Janis