[Webkit-unassigned] [Bug 34569] Don't call CRASH() in fastMalloc, fastCalloc and fastRealloc when the requested memory size is 0

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34569





--- Comment #5 from Kwang Yul Seo <kwangyul.seo at gmail.com>  2010-02-04 17:27:27 PST ---
(In reply to comment #3)
> (From update of attachment 48126 [details])
> I suspect higher level code depends on not getting 0 when a size of 0 is
> passed. A better fix may be to change the size from 0 to 1 on the BREW system.

I agree, but I don't want to introduce size check on the BREW system because it
adds additional overhead to every allocation. 

This isn't a BREW specific issue because malloc can return 0 in other systems
too.

Why don't we simply retry when malloc(0) returns 0?

void* fastMalloc(size_t n)
{
    ASSERT(!isForbidden());

#if ENABLE(FAST_MALLOC_MATCH_VALIDATION)
    TryMallocReturnValue returnValue = tryFastMalloc(n);
    void* result;
    returnValue.getValue(result);
#else
    void* result = malloc(n);
#endif

    if (!result)
        // malloc(0) can return 0.
        // To make sure that fastMalloc never returns 0, increase the size
        // to 1 and try again. This introduces no additional overhead
        // in usual allocations.
        if (n)
            CRASH();
        else
            return fastMalloc(1);

    return result;
}

It adds no overhead because non zero size request never returns 0 unless
allocation fails.

However, I am not sure what to do with realloc because realloc(p, 0) is
equivalent to free(p). This is the exact duplicate of 
https://bugs.webkit.org/show_bug.cgi?id=29026

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.