Re: Buffer contents well-defined after fgets() reaches EOF ?

On 16.02.2025 09:48, Michael S wrote:

On Sun, 16 Feb 2025 04:29:20 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

>
Moreover, I prefer functions with a simpler interface to functions
with a more clumsy one (I mean the 'char **saveptr' part); so why
use the complex one in the first place if it just complicates its
use and reduces the code clarity unnecessarily.

 
I don't see how explicit context variable can be considered less clear
than context hidden within library in non-obvious way [...]

Explicitly maintaining unnecessary parameters and providing additional
code for the logic to handle that unnecessarily is not obviously less
clear to you? - Then I cannot help you, sorry.

 

Re "more problematic functions in C library"...
I had to chuckle on that; if you're coming from other languages
most "C" functions - especially the low-level "C" functions that
operate on memory with pointers - don't look "unproblematic". :-)

 
I tend to have no problems with low-level C RTL functions, in
particular those with names start with 'mem'.

*shrug*

I recall (in early C++ days when there wasn't yet a string type) to
have based a set of string functions on the mem...() type functions
(as opposed to the str...() type functions); it wasn't more difficult.
Rather the effects had been (a) that we could operate binary strings,
(b) that it was (slightly) faster code, and (c) that some code could
get even simpler.

More problems with some
of those that try to be "higher level", for example, strcat(). Even more
with those that their designers probably considered 'object-oriented',
like strtok().

I don't consider strtok() being 'object-oriented', rather the opposite
because of the globally static attribute it has. OO objects typically
carry their own state (unless you deliberately implement a Singleton
pattern).

Janis