Re: avoiding strdup()

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.