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

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

On 15.02.2025 18:29, Michael S wrote:

On Fri, 14 Feb 2025 20:51:38 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: 

>
Actually, in the same code, I'm also using the strtok() function 

 
strtok() is one of the relatively small set of more problemetic
functions in C library that are not thread-safe. 

 
I know that it's not thread-safe. (You can't miss that information
if you look up the man page to inspect the function interface.)
 

If you only care about POSIX target, the I'd reccomend to avoid
strtok and to use strtok_r(). 

 
But since I don't use threads - neither here nor did I ever needed
them generally in my "C" contexts - that's unnecessary. Isn't it?
 
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 (see post of Kaz
that points out that there are at least two options of how exactly it
could be handled, with different semantics).

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". :-)
 
Janis
 

I tend to have no problems with low-level C RTL functions, in
particular those with names start with 'mem'. 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().