Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Buffer contents well-defined after fgets() reaches EOF ?
Date: Sun, 16 Feb 2025 19:14:31 +0100
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <vot9u9$n1k4$1@dont-email.me>
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> <20250216104844.00000473@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 16 Feb 2025 19:14:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="aaf6e5d3524c9b1f9a0562d9d6447128";
	logging-data="755332"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+0ccQyQwECHyI3aK5SR8FW"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:A2FHvL0DVDt/5AZilPJ90tTQLEU=
In-Reply-To: <20250216104844.00000473@yahoo.com>
X-Enigmail-Draft-Status: N1110
Bytes: 3511

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