Re: portability question

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-12-16 at 02:15, Sheldon Simms wrote:
> Hi everyone,
> 
> I just started reading some of the GLib source code
> for the first time and I have noticed that the code
> often makes "nonportable" assumptions about the C
> implementation like arbitrary pointer/int
> interchangability, twos-complement representation of
> negative integers, "all-zeros" representation of a
> null pointer.
> 
> I say "nonportable" in quotes, because I suspect that
> these things actually are portable to all platforms of
> current interest, but still I wonder why the code was
> written this way when it's really not difficult to
> write the code without making these assumptions.
> 
> Are there any reasons?

 - We don't assume arbitrary pointer/int interchangeability

   We *do* assume that it's possible to store "small"
   (basically 32-bit) integers in pointers. This is very
   convenient for things like g_object_set_data() - we
   can actually store an integer as data, rather than
   having to malloc a separate 4 byte chunk.

   There are GINT_TO_POINTER()/GPOINTER_TO_INT() that
   encapsulate this operation.

 - I can't think of many places where we assume twos-complement
   integers. There may be one or two places bit-manipulation
   sections in graphics code that do this.

 - Assuming the all-zeros representation of a NULL pointer 
   allows use of memset to clear pointer arrays, and avoids
   a lot of assignments for newly created objects - reducing
   code size, increasing performance, and increasing clarity.

Could we do without these? Yes. But it would make the code
harder to read and GTK+ slower for no good reason,

Regards
					Owen

]
The other "non-portable" assumption we make in many places 
is that it's possible to ignore function call parameters.
If you have a function 

 int (*foo) (int a)

then (with the approriate cast), you can call it as:

 result = (*foo) (1, 2);
]