Re: Moving to pointer-sized GType?

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> > 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.
> 
> that is not good enough, we can already segfault when dereferencing
> such a thing, and basically needs a function that returns
> is_registered_type_id(num). that's e.g. for things like figuring whether
> a certain type has already been registered when you're about to register
> a fixed type id, or for g_return_if_fail() in functions that take
> type ids.
> 
> > (Remember, we don't have 100% certainty currently, since a random
> > value can accidentally be a valid type.)
> 
> g_type_name(id)!=NULL is a 100% correct check to figure whether id is
> an already registered type id, and is actually recommended as such
> curently.

This may be true according to your docs, but its simply not a
reasonable operation. For assertion checks there is no more reason
that this shouldn't segfault than to expect GTK_IS_WIDGET() shouldn't
segfault when called on random junk memory.

I see no reason to make g_type_name crawlingly slow to avoid it
segfaulting when things have gone horrible wrong and your are going to
segfault a few lines later anyways.

The _only_ possible excuse for such a function is use inside a gdb
session, and for that purpose, we could simply write a gdb macro to do
the check and put a gdb-macros-for-glib-hackers file inside docs.

(gdb macros won't segfault because they are run inside the debugger
not inside the debugged process.)

Regards,
                                        Owen