We're updating the issue view to help you get more done. 

make sure ICU4C itself never calls global new/delete

Description

ICU4C itself must never call the global new/delete operators. Instead, it must
use uprv_malloc() etc. for all memory management, and C++ classes must inherit
UMemory which implements its own new/delete operators in terms of uprv_malloc()
etc.

See uobject.h/.cpp and cmemory.h/.c

This used to be easy to verify; see uobject.cpp for details. Essentially, the
compiled object code could be examined with development tools and scanned for
whether they import the global new/delete.

ICU 2.4 added virtual destructors to interface/mixin classes. Virtual
destructors are required on all classes with virtual functions so that the
correct destructors get called. ICU4C implementations of such interface/mixin
classes also (and first) inherit UObject or UMemory, so actual implementations
always use UMemory's new/delete.

Still, the compiler generates a body for the interface's destructor itself, and
that destructor uses the global delete because the compiler does not know that
all implementations will in fact use UMemory's.

This provides a problem for the verification that memory usage is correct - the
global delete is import though not used.

We need to modify the memory usage verification:
a) Still check for imports of global new/delete (see uobject.cpp)
b) Verify that new is never imported.
c) Verify that delete is only imported from object code for interface/mixin
classes.
d) Add global delete and delete[] only for the ICU4C library itself
and define it in a way that crashes or otherwise easily shows a problem.

Status

Assignee

Markus Scherer

Reporter

TracBot

Labels

Reviewer

None

Time Needed

None

Start date

None

Components

Fix versions

Priority

blocker