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 11:30:32 -0700
Organization: None to speak of
Lines: 26
Message-ID: <87il1saaev.fsf@nosuchdomain.example.com>
References: <us0brl$246bf$1@dont-email.me>
	<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>
	<87edcgzo7r.fsf@nosuchdomain.example.com>
	<UCHHN.125446$TSTa.5399@fx47.iad>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="803e1d91970c7135fb6b17cffb70db2d";
	logging-data="3955985"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/kjYxy2X/Io2lvbGVWdjRz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:+jAiF8EzQyuniXv4s1je5Z9x1g4=
	sha1:W/EeA8vDaWgg5d8VrCMCyFTMcXs=
Bytes: 2565

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Michael S <already5chosen@yahoo.com> writes:
>>[...]
>>> 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.
>>
>>strdup() calls malloc(), so strdup() can return NULL if and only if
>>malloc() can return NULL -- but with the additional constraint that you
>>first need to have a string argument to strdup() that's long enough to
>>cause a suffiently large argument to be passed to malloc().
>>
>>One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
>>very large arguments (over about 23 GiB in my quick and dirty test).
>
> That may be due to resource limits (setrlimit/getrlimit/ulimit) on
> the size of the address space.

I don't see anything relevant in the output of `ulimit -a`.  In
particular, "data seg size" is unlimited.

-- 
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 */