Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Buffer contents well-defined after fgets() reaches EOF ?
Date: Sun, 16 Feb 2025 10:48:44 +0200
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <20250216104844.00000473@yahoo.com>
References: <vo9g74$fu8u$1@dont-email.me>
	<vo9hlo$g0to$1@dont-email.me>
	<vo9khf$ggd4$1@dont-email.me>
	<vobf3h$sefh$2@dont-email.me>
	<vobjdt$t5ka$1@dont-email.me>
	<vobkd5$t7np$1@dont-email.me>
	<20250210124911.00006b31@yahoo.com>
	<86ldu9zxkb.fsf@linuxsc.com>
	<20250214165108.00002984@yahoo.com>
	<20250214085627.815@kylheku.com>
	<voo6sc$3k640$1@dont-email.me>
	<20250215192911.0000793d@yahoo.com>
	<vorm2j$eag8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 16 Feb 2025 09:48:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="490a7a8232977f53c3c7e3489ae7e715";
	logging-data="552049"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1rnqs8THT3f8TuhXH23EIVZjvh0zL0hE="
Cancel-Lock: sha1:HL20IZGY62tgzPXgpjxniJp0RTU=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3344

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().