424420 - analysis wanted: XPCOMGC pointer classes

Status: RESOLVED WONTFIX

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Benjamin Smedberg]

For XPCOMGC I logically have different flavors of "void*":

* void* pointing to non-GC memory
* void* pointing to somewhere in the middle of GC memory (an inner pointer)
* void* pointing to the beginning of a GCed memory block (an outer pointer)

For certain functions such as void MMgc::writeBarrier(const void *container, const void *address, const void *value), the "container" must be an inner pointer, the "address" is an inner pointer, and the value is an inner pointer.

I would like to enforce those restrictions, somehow. There are a set of rules that I haven't perfected yet for going from an inner GC pointer to an outer pointer, and we might want to invent a new cast operator too.

I'm thinking about something like `typedef void InnerGC __attribute__((user("NS_InnerGC")));` except I can't seem to get any attribute data in dehydra, which might be a bug... I'll file that separately.

Comment 1

[(dormant account)]

Is there a reason why you want to check attributes instead of typedef names?

Comment 2

[Benjamin Smedberg]

Well... I already have user attributes for GC types, so extending those to a typedef of void reduces the amount of special-case logic I'll need... but hardcoded special names would work too.

The question of pointer classes is also related to similar analyses I want to do, such as "non-GC objects containing pointers to GC objects".

Comment 3

[Nathan Froyd [:froydnj]]

XPCOMGC is not a thing.