Re: [ooc-compiler] oo2c-2.0.18 allocator problem

[Frank C. <fj...@wo...>]

On Tue, Feb 10, 2004 at 08:06:46PM +0100, Tim Teulings wrote:

> This is already fixed in CVS and if I remember correctly occured with 
> older version of oo2c, too. It seems like memory initialisation is 
> different among the installed systems. While in theory memory should not 
> be initialized at all (see manpage of malloc), it seems like it is on 
> most systems. This is bad, since the compiler does not warn you. The 
> questions is, who is responsible? libc? The gc? Is it realy always by 
> accidient that most of the time memory seems cleared?

The Oberon-2 language doesn't guarantee any variables are initialised, but
there's a strong implication that pointer and procedure variables are
guaranteed to be either NIL or point to a valid object. Otherwise pointers
are no safer than in C, which is supposed to be one of the strengths of the
language.

> So it seems, like GC_MALLOC does not always clear memory?

It says so explicitly in 'man GC_MALLOC', but not in gcinterface.html. In
both places it states that GC_MALLOC_ATOMIC does not clear memory. This is
Debian testing, libgc1 is version 6.2+6.3alpha2-1.

Looking at the changes to RT0_NewObject I can't see anything that would
cause it to use GC_MALLOC_ATOMIC by mistake, so I think you may be right.
The fact that a string doesn't get initialised isn't the issue, it's the
possibility that objects can be created containing invalid pointers.

Frank Copeland
-- 
This fortune would be seven words long if it were six words shorter.