Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!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:28:15 -0700
Organization: None to speak of
Lines: 38
Message-ID: <87msr4aaio.fsf@nosuchdomain.example.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>
	<20240311185039.000066fc@yahoo.com>
	<87edcgzo7r.fsf@nosuchdomain.example.com>
	<20240311105508.215@kylheku.com>
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="U2FsdGVkX19tTX/QlP+O7eXH4NNww/Ma"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:/HPdn6Gk2miTXHUZKO8Sg6pURz8=
	sha1:HSwnGDvBEwI9W1zndThYNaYhxO8=
Bytes: 3126

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> 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).
>
> I'm guessing that might be only be because of the overcommit_ratio
> value; i.e that allowing a 23 GiB increment in the allocated address
> space would bring the system over the currently configured overcommit
> ratio.

Good guess, but I don't think so.

    $ cat /proc/sys/vm/overcommit_memory
    0
    $ cat /proc/sys/vm/overcommit_ratio
    50

(These are the default values.)  If I'm reading the proc(5) man page
correctly (which is questionable), 0 means "heuristic overcommit", and
overcommit_ratio is ignored unless the mode is set to 2.

I have 12 GB of physical memory.

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