Re: Moving to pointer-sized GType?

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 14 Sep 2001, Dan Winship wrote:
> 
> > > The change will be fully source compatible for code that correctly uses 
> > > GType, but unfortunately there are some places in our codebases that use 
> > > uint instead of GType/GtkType to store/handle types, and these will break 
> > > on 64bit architectures (warning + segfault), but silently work on 32bit 
> > > architectures.
> > 
> > Adding more ways for the teeming 32bit-only hordes to unwittingly break
> > things for 64bit architectures seems bad. Couldn't you just make GType
> 
> right, that is my main concern with alex approach to go to pointer sized
> GType. others are:
> - g_type_parent(r=rand()) will not just puke on you (actually it's currently
>   silent, but _should_ puke), but plain segfault if r is assumed to be
>   castable into a valid pointer.

This is fine.

> - g_type_name(rand()) _must_ continue to work, as that's the recommended
>   way to figure whether a type id is at all valid (it just returns NULL
>   silently, for invalid type ids). so for this, we'll have to do an extra
>   lock and keep track of valid pointers to figure invalid things passed in.

This is no more of a valid operation than:

 gtk_widget_show ((GtkWidget *)rand());

The only reason why I can think of wanting to this to not segfault
is for 'invalid cast from (Unknown) to GtkWidget' style warnings,
but we will get a segfault there anyways before we go to 
print the name, and we currently get a segfault quickly after
such warnings in most cases.

g_type_name() may be semi-performance critical in usages like
language bindings, and I'd rather not make it a crawlingly slow 
to try and avoid segfaults on invalid arguments.

If you _really_ are worried about this, what I would suggest
is putting a magic value at the start of GTypeNode structures
which should allow you to catch invalid values with  high
probability.

(Remember, we don't have 100% certainty currently, since a random
value can accidentally be a valid type.)

Regards,
                                        Owen