Re: problem compiling GTK 1.1.1

[Owen Taylor <otaylor redhat com>]

Winfred van Kuijk <winfred@usa.net> writes:

> Thanks for the responses sofar. One solution is 
> to modify the right hand side, which is a pain.
> 
> A cleaner solution is to modify the macros so
> they will be accepted by a ANSI C compiler
> (or: gcc -pedantic -Wall).
> 
> Example for the GPOINTER_TO_INT:
> 
>   #define GPOINTER_TO_INT(p) ((gint)(p))
> 
> should be changed to:
> 
>   #define GPOINTER_TO_INT(p) (*(gint *)&(p))

The main problem with this is that if you happen to have 64 bit ints
and 32 bit pointers, then this will cause a segfault from bad
alignment. (I'm not sure if GTK+ works for -N64 on SGI's now, which is
this case, but the reverse is commonly found - so this would not work
at all for GINT_TO_POINTER). Also, it will suppress p being put into a
register.

Much better:

> > >         GPOINTER_TO_INT (list->data) = row2; 

should simply be:

 list->data = GINT_TO_POINTER (row2);

> Any volunteers for the following?
> 
> #define GTK_CTREE_ROW(_node_) ((GtkCTreeRow *)(((GList *)(_node_))->data))
> #define GTK_CTREE_NODE(_node_) ((GtkCTreeNode *)((_node_)))
> #define GTK_CTREE_NODE_NEXT(_nnode_) ((GtkCTreeNode *)(((GList *)(_nnode_))->next))
> #define GTK_CTREE_NODE_PREV(_pnode_) ((GtkCTreeNode *)(((GList *)(_pnode_))->prev))

These need, I think just to be avoided on the LHS. (Since data is 
a void *, these could be in ANSI C, written as:

  #define GTK_CTREE_ROW(_node) (_node_)->list->data

etc, at the loss of some type safety and portability to C++...) Even
for pointers (where it should be at least safe), reinterpret casting
should be avoided.

Regards,
                                        Owen