[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ptrdiff_t overflow checks for malloc-posix etc.

From: Paul Eggert
Subject: Re: ptrdiff_t overflow checks for malloc-posix etc.
Date: Sun, 18 Apr 2021 13:24:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 4/18/21 5:11 AM, Bruno Haible wrote:
Paul Eggert wrote:
Come to think of it, why do we have both malloc-gnu and malloc-posix
modules (and similarly for calloc and realloc)?

Package owners had two decisions to make:
   "Does my package ever call malloc (0)? - If yes, I need 'malloc-gnu'."
   "Does my package attempt portability to native Windows? - If yes, I
    need 'malloc-posix'."

Sure, but that sort of approach doesn't scale well. Now that we know the issues better, that approach would require package owners to answer 11 questions:

A (for malloc, realloc, calloc). Does my package need errno to be set when malloc/realloc/calloc fails?

B (for malloc, realloc, calloc). Does my package require malloc/realloc/calloc to fail if it would create an object with more than PTRDIFF_MAX bytes?

C (for malloc, realloc, calloc). Does my package require malloc/calloc to return NULL if and only if it fails, and similarly for realloc (P, N) when !P || N?

D (for realloc). Does my package require realloc (P, 0) with nonnull P to free P and return NULL?

E (for calloc). Does my package require calloc (N, S) to fail when N * S would exceed SIZE_MAX?

And I've probably forgotten one or more questions.

Should we have 11 different modules, one for each question? Surely not. We shouldn't expect other packages to carefully select exactly which of these 11 questions they need GNU compatibility with. Such a selection will be error-prone and won't be well-tested if we get the selections wrong.

It's also not reasonable to test all 2**11 combinations of answers to these questions. Some combinations will never occur, and others will be rare and hard to be tested.

Instead, I suggest that we simply implement malloc, realloc and calloc the GNU way on all platforms. Packages that rely on any GNU malloc feature can simply require the malloc-gnu module without worrying about individual questions.

Come to think of it, it might be better to have a single module (say, alloc-gnu) check and fix all three functions (malloc, realloc, calloc) as that'd be simpler yet.

For example, if my package never calls malloc (0) but desires portability
to native Windows, would I want that *every* malloc call on *all*
non-glibc platforms goes through hoops before it reaches the malloc()
function in libc?

I would want that, yes, because that'd be more reliable than what we were doing. Any performance penalty on non-GNU platforms is surely insignificant in real applications, and so is outweighed by the reliability improvement. Admittedly it's hard to measure the reliability improvement, but I've already fixed an unlikely bug or two as part of this cleanup, and I won't be surprised to fix more.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]