Re: Moving to pointer-sized GType?
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Dan Winship <danw ximian com>, Alex Larsson <alexl redhat com>, Hacking Gnomes <gnome-hackers gnome org>, GNOME MList <gnome-list gnome org>
- Subject: Re: Moving to pointer-sized GType?
- Date: 18 Sep 2001 12:43:47 -0400
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
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]