Porting woes

[Martin v. Loewis]

jstavnitzky at atsautomation.com (Jay) writes:

> Thanks for the suggestion!! It appears as though this particular
> problem goes away if I extend the static initialization of the
> PyTypeObject PyBaseObject_Type to explicitly set the tp_bases value
> (and the other six values that are not explicitly assigned at the end
> of the structure to NULL).  If I don't explicitly zero these values,
> they pick up whatever happens to be left over in those memory
> locations, is it possible that this is a compiler bug?? 

If the compiler fails to zero-initialize fields that are defined in
the struct, but not provided in the initializer, then yes, that's a
compiler bug.

> I assume that this code compiles correctly on most other compilers,
> or is zeroing out memory locations before use an operating system
> function??

It depends on the system. Typically, the "system" zero-initializes all
objects which are completely uninitialized, by means of the .bss
section (although the "system" might be a user-space function here,
such ld.so.1). For partially-initialized data, the compiler puts them
into the .data section, which typically requires complete
initialization in the assembler file.

> I hope that there aren't other places in Python where structures are
> not fully initialized (and I may see a bug of this type again).

Dozens. Virtually every type object is incomplete, as are method
tables in many cases.

Regards,
Martin