Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: avoiding strdup()
Date: Mon, 11 Mar 2024 18:20:38 -0700
Organization: None to speak of
Lines: 62
Message-ID: <87sf0w8cux.fsf@nosuchdomain.example.com>
References: <us0brl$246bf$1@dont-email.me>
	<pan$4fc39$61bdfbef$3ca9a71a$af842694@invalid.invalid>
	<87y1ayj6hs.fsf_-_@bsb.me.uk>
	<pan$e9f7e$d6f7a386$31c353e8$a08c13cf@invalid.invalid>
	<usc845$10v6e$1@dont-email.me>
	<pan$89aca$33d2df8c$9e2c232f$d767db40@invalid.invalid>
	<ushea7$28prq$2@dont-email.me> <ushnkb$1rnlb$4@dont-email.me>
	<87r0gizzuo.fsf@nosuchdomain.example.com>
	<20240310101101.00001fd4@yahoo.com> <20240310100715.866@kylheku.com>
	<ifnHN.386274$vFZa.250421@fx13.iad> <usnb64$3n297$1@dont-email.me>
	<yMGHN.481214$PuZ9.381006@fx11.iad> <usoa6a$3tqji$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="de8f53c78bf32f77c14d770a36ea4d62";
	logging-data="4123696"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/e9Xosb3pavG9kjrfd5hq6"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:Is7eHEN/1qcWu4FwpOyjAz0PEG4=
	sha1:WoNuGlm17tLSWSJd8Hnh+2KRLhA=
Bytes: 4009

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 11/03/2024 17:00, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 10/03/2024 18:47, Scott Lurndal wrote:
>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote:
>>>>>> On Sat, 09 Mar 2024 16:37:19 -0800
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>>> strdup() and strndup() are being added to the C23 standard.
>>>>>>>
>>>>>>
>>>>>> What is justification?
>>>>>
>>>>> strdup is required by POSIX already and thus widely implemented.
>>>>> Many programmers who are not into standards already assume it's in C.
>>>>>
>>>>> For decades, portable programs have been doing things like this:
>>>>>
>>>>> #if HAVE_STRDUP
>>>>> #define xstrdup(s) strdup(s)
>>>>> #else
>>>>> char *xstrdup(const char *); // own definition
>>>>> #endif
>>>>>
>>>>>> What strdup() can do better, for any chosen value of better, than
>>>>>> strlen()+malloc()+memcpy() ?
>>>>>
>>>>> Not take up space in every application for a common library routine.
>>>>
>>>> It's a form of lazy programming.  I've seen a lot of open source
>>>> code that uses strdup without checking for failure and frequently
>>>> "forgetting" to free the result.
>>>
>>> And it is probably more likely that machine with many gigabytes of RAM
>> Actually, your assumptions that:
>>    1) strdup is the only allocation function used by an application
>>    2) all strings are "short"
>> are both flawed.
>> 
> The bank has many billions. But there is a banking crisis on and it is
> about to fail. And someone, somewhere, will be that man who tries to 
> withdraw some money and is told "no". But how likely is that man to be
> you with your 20 pounds at the cashpoint? How likely is it to be
> another bank making a cash call for a 100 million or so?

If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds that
the bank still checks whether it has the money.

I'd rather write correct code than code that almost certainly happens to
work.  Sure, strdup() is unlikely to fail-- but I'm going to check the
result.

> And how often do banks fail, actually, and how often does government
> take action when it's heading that way, but nowhere near failing yet?

The government isn't going to intervene when your laptop is running low
on memory.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */