Re: avoiding strdup()

On Mon, 11 Mar 2024 17:05:40 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Michael S <already5chosen@yahoo.com> writes:

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.
 

 
An unanswerable question.   But, consider that not all allocations
in an application use strdup as the only memory allocator (the
majority don't, and other allocations may be much larger), yet both
use the same pool of address space and host memory.
 
Consider also that on unix and linux, there are a number of resource
limits intended to prevent a single application from consuming all of
memory, which a call to strdup may encounter even with plenty of RAM
available.
 
Toy applications may not have an issue with strdup.   Real
applications on the other hand might, and an unexpected SIGSEGV is
extremely user-unfriendly and could have catastrophic results.
 

According to my understanding, on Linux with overcommit enabled,
typical behavior would be that allocation (of non-extravagant size,
say, no more than 100 MB) always succeeds. OOM is called later, on
access. It seems, that most commonly OOM does not hit application that
is allocating right now. Much more likely that it will kill app that
user opened hours ago, then put aside and then tried to use again.

And on the gripping hand, not testing for a potential catastrophic
failure condition, no matter how unlikely isn't the sign of a good
programmer.

Some people would say that writing code (a handler for allocation
returning NULL) that either can't be tested in principle or can be
tested only in principle, but most certainly not tested in
practice, isn't a sign of a good programmer.
Myself, I still tend to code this checks, but
(1) my main targets are not Linux with overcommit, so the
chance of allocation returning NULL could be estimated like "not going
to happen" rather than "can't happen".
(2) I am old full that like his unreasonable old habits

At least, I stopped checking return value of fclose() after being told,
with facts, how stupid it is. So, may be, one day I'd convince myself to
stop checking return value of malloc() as well.