Path: ...!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 19:35:11 +0200
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <20240311193511.0000610f@yahoo.com>
References: <us0brl$246bf$1@dont-email.me>
	<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>
	<20240311185039.000066fc@yahoo.com>
	<ERGHN.481215$PuZ9.417692@fx11.iad>
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+KKvgM6JmT+jTZ6VjCAIiYlJ6lYHEuF8s="
Cancel-Lock: sha1:+7qVM4tZskJPJAJEdx9EPHbBVqM=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5341

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.