Re: portability question

[Sheldon Simms <wsxyz6294 yahoo com>]

Owen Taylor <otaylor redhat com> wrote:
>  - 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.

What I meant by assumption of arbitrary pointer/int
interchangeability was things like this (from
gtype.c):

 static inline TypeNode*
 lookup_type_node_I (register GType utype)
 {
   if (utype > G_TYPE_FUNDAMENTAL_MAX)
     return (TypeNode*) (utype & ~TYPE_ID_MASK);
   else
     return static_fundamental_type_nodes[utype >>
G_TYPE_FUNDAMENTAL_SHIFT];
 }

Since GType is actually an unsigned long and there is
no guarantee in the
C standard that an arbitrary pointer value can be
stored in a value of
unsigned integer type. This could be done portably
like this:

 typedef uintptr_t GType;
 ...
 static inline TypeNode*
 lookup_type_node_I (register GType utype)
 {
   if (utype > G_TYPE_FUNDAMENTAL_MAX)
     return (TypeNode*)(void *)(utype &
~TYPE_ID_MASK);
   else
     return static_fundamental_type_nodes[utype >>
G_TYPE_FUNDAMENTAL_SHIFT];
 }

Because a uintptr_t is guaranteed to be able to hold a
void * and the double
cast makes sure that any necessary conversions between
a void * and a
TypeNode * are done.

>  - 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.

Well the particular example I was thinking of turns
out to be ok after all,
as far as I can tell after reviewing the standard.

>  - 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.

I doubt that performance or code size are affected in
any noticable way,
and one could argue that clarity is only increased for
people who don't
know that a null pointer can be anything other than
all-zero bits. When
I see a pointer being memset to 0, I find the code
questionable, not clear.

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

I don't wish to argue that anyone should comb through
the code and "fix"
these assumptions. That would only be an invitation to
create more bugs
through botched "fixes", and the code works for all
platforms of interest.
But I find it difficult to believe that the code was
intentionally written
like this for reasons of efficiency or clarity, in
full knowledge of its
nonportability.

-Sheldon


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree