Is your realloc really necesary

NEW
Unassigned

Status

Core Graveyard
GFX: Mac
15 years ago
10 years ago

People

(Reporter: Ben Fowler, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Build Identifier: self built Camino version 0.7

I too am a reader of MacGuire's WCS, and whilst looking for the cause
of some wildly oversized memory requests in Thunderbird, I found that
nsMemory::Realloc( ) was being called with a null pointer.

Is this desirable?

Reproducible: Always

Steps to Reproduce:
1. Not relevant
2.
3.



Expected Results:  
I expect to be able to put a sanity check on memory internals of Mozilla

If you have read this far, you probably know that realloc when called
with a null pointer behaves like malloc.

Personally, I would prefer one of two symmetries:

A malloc( )balanced by free( )
B malloc( ) folloed by optional realloc( )s balanced by free( )

This requires the discipline to not knowingly pass a null pointer
to realloc, and gains the benefit of being able to assert on the 
value of pointer passed it.

I'm making this a severity of normal, but it is actually 'code quality'
less than normal.
> I found that nsMemory::Realloc( ) was being called with a null pointer.

Called by whom?  This bug should be filed on the component doing that call.


Though I have to ask:

> B malloc( ) folloed by optional realloc( )s balanced by free( )

How is this substantively different if the malloc() is not called?

> and gains the benefit of being able to assert on the value of pointer passed
> it

Why is this a benefit?

Comment 2

15 years ago
Realloc() with a NULL pointer is valid behaviour according to the ANSI standard,
and should behave identically to malloc(). But not every implementation does
that, and it's always wise to avoid portability problems.
(Reporter)

Comment 3

15 years ago
I was thinking of NS_IMETHODIMP nsRegionMac::GetRects(nsRegionRectSet **aRects)
in file nsRegionmac.cpp .

Did I mention that this seems to be called repeatedly whilst
Camino is idle?
(Reporter)

Comment 4

15 years ago
I hesitate to take issue with ZB, but my point is that malloc( )/free( )
balances, and realloc( )/[realloc( )]* is also OK; I think that such schemata
are easier to check for correctness, more scrutable, than ones in which
realloc does the work of malloc, and one is trying to balance a free( )
with a preceding realloc( ).

I haven't come across a C system which gets this wrong, but I know many 
programmers (including myself once) who are unaware of the behviour of realloc( ).

Now that I do know, I never exploit its nuances ...
Over to the right component.

Ben, of you can produce a patch that would expedite things greatly... I'm not
aware of anyone actively working on Mac GFX.
Assignee: general → sfraser
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX: Mac
Ever confirmed: true
(Reporter)

Comment 6

15 years ago
I'm travelling to London for the Mac Expo shortly, I will certainly produce 
a patch and test it, but it may be a few weeks before I would be happy
to submit it to scrutiny!

Updated

10 years ago
Assignee: sfraser_bugs → joshmoz
(Assignee)

Updated

10 years ago
Product: Core → Core Graveyard

Updated

10 years ago
Assignee: joshmoz → nobody
You need to log in before you can comment on or make changes to this bug.