GNOME Bugzilla – Bug 303543
GType casts and checks are not const-correct
Last modified: 2013-11-24 02:00:13 UTC
Distribution/Version: Debian/3.1 It is not possible to use const GObjects safely with the current glib/gobject. G_TYPE_CHECK_INSTANCE/g_type_check_instance gboolean g_type_check_instance (GTypeInstance *instance); should be gboolean g_type_check_instance (const GTypeInstance *instance); G_TYPE_CHECK_INSTANCE_CAST is OK, but there should be a corresponding G_TYPE_CHECK_INSTANCE_CONST_CAST for const objects (g_type_check_instance_const_cast replacing g_type_check_instance_cast). G_TYPE_CHECK_INSTANCE_TYPE/g_type_instance_is_a: gboolean g_type_check_instance_is_a (GTypeInstance *instance, GType iface_type); should be gboolean g_type_check_instance_is_a (const GTypeInstance *instance, GType iface_type); G_TYPE_INSTANCE_GET_CLASS: #define _G_TYPE_IGC(ip, gt, ct) ((ct*) (((GTypeInstance*) ip)->g_class)) should be #define _G_TYPE_IGC(ip, gt, ct) ((ct*) (((const GTypeInstance*) ip)->g_class)) G_TYPE_INSTANCE_GET_INTERFACE/g_type_interface_peek gpointer g_type_interface_peek (gpointer instance_class, GType iface_type); should be gpointer g_type_interface_peek (const gpointer instance_class, GType iface_type); (the const cast is safe to do internally, since all GObjects will be writable even if they are const, and will then support both const and non-const objects). G_TYPE_CHECK_CLASS_CAST/g_type_check_class_cast: as for g_type_interface_peek, GTypeClass could be const. The other GType macros and functions similarly need checking. Making gobject/glib usable with const objects is important for the application programmer /using/ glib, since if glib isn't const-correct, const-correct application code will cause huge spews of GCC compiler warnings when warnings are turned on. This makes it very difficult to spot real errors. For the sake of a few const warnings when building glib (the const->non const casts will occur in glib rather than application cods), glib will become safer to use. If you agree with this assessment, I can make some patches to correct this. Regards, Roger
There is some effort to treat char * const-correct, but we generally don't clutter the apis with consts for refcounted types.
Why don't you use consts for refcounted types? const is a contract between the user of an interface and its implementation. It's saying, "this function will not modify this object". It doesn't matter if the object is never "truly const", like all GObject-derived types; it's just part of the contract. The constness can always be cast away if required. For example, a ref/unref of a const object behind my back isn't really violating the contract. The fact that GType has no way to handle const types makes it very difficult for a programmer to write const correct code. Compiling my gobject-using code with compiler warnings produces nothing but hundreds of lines of const-cast warning spew. As an example, please check out the interfaces of a couple of the modules I wrote: http://arch.debian.org/cgi-bin/archzoom.cgi/rleigh@debian.org--2005-uterm/uterm--mainline--0.1--patch-41/uterm/uterm-code-table.h?color=default http://arch.debian.org/cgi-bin/archzoom.cgi/rleigh@debian.org--2005-uterm/uterm--mainline--0.1--patch-41/uterm/uterm-code-table-map.h?color=default http://arch.debian.org/cgi-bin/archzoom.cgi/rleigh@debian.org--2005-uterm/uterm--mainline--0.1--patch-41/cse/cse-selection.h?color=default I've worked hard to make these interfaces const (and restrict) correct, but glib does not provide the necessary facilities to apply good programming practice. IMHO an important library like glib should be setting the bar a little higher; glib is highly-regarded, and should be an example of programming excellence. It should certainly not actively hinder my application of good practices to my own code. For me, "const" isn't clutter, it's an essential part of my interface design. This is not the first time I've come across problems of this sort. A while ago, I found a number of problems when compiling a GTK+ program with high GCC warning levels. I mentioned it to a GTK+ developer, whose comment was along the lines of "only pedants compile with warnings enabled". Libraries should not prevent me writing correct code!! Moreover, their headers should not give warnings when compiling with warnings enabled: it is not unreasonable to expect correct headers. That's a separate issue, though. Regards, Roger
Roger, you have a good point here, especially since gtype.c doesn't ref-count instances, please supply a patch for gtype.[hc]. and yes, library *headers* shouldn't generate warnings for you in any case (except maybe for particularly broken compiler versions).
marking NEEDINFO since no patch has been supplied in 10 months.
NEEDINFO is meant for questions against the reporter, not for asking for patches. Reopening.
Created attachment 157654 [details] [review] Bug 303543 — GType casts and checks are not const-correct Make all the relevant functions and macros in gtype.h const-correct. Closes: bgo#303543
I'm not quite sure about whether the instance_real_class_* stuff should be const, but it doesn't modify the class or instance pointers at all.
I don't think we want to try and retrofit const-correctness for objects into our APIs at this point.