Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: avoiding strdup()
Date: Mon, 11 Mar 2024 18:50:39 +0200
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <20240311185039.000066fc@yahoo.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="20135147cba2d202cd079ad5c3141fdd";
	logging-data="3784551"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+k5midifdyNXJ8We7OfKzn4+O8fOcobz8="
Cancel-Lock: sha1:WodFPq4vn9SryrsQ34vqvamwTDU=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3068

On Mon, 11 Mar 2024 16:23:32 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> 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 will develop an electrical fault than that that call for a short
> string will be the point where it runs out of memory.

Is there any chance at all that on typical Linux machine (i.e. the one
configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.