On Wed, 2010-06-02 at 14:31 +0100, Patrick Welche wrote: > > Just don't do this. Returning a pointer to a stack-allocated structure > > is just screaming "SIGSEGV". > > Which is why this isn't committed ;-) But finally you see the point? yes. it sucks to maintain an application. > > I can agree that updating applications to work with GTK+-3 will be a > > major pain in the *** in some cases (yours being one example), but I > > fail to see why would newly written applications need to suffer from > > inconsistent API just to make old apps a bit happier (they will still > > need to be updated). > > This all seems odd to me because the widget contains the allocation already. yes, and giving you the pointer to the allocation would be dangerous and stupid. and against the idea of moving everything behind the instance private data wall that has driven the gtk+ 3.x effort. > I don't give the address of a GtkWidget to some_widget_new() for it to > fill in the structure. I call some_widget_new() and it returns a pointer > to the widget which contains the allocation... All I need is a pointer to > that allocation. I don't understand the motivation for having to copy the > allocation... because if you get a pointer to an internal data structure you're allowing people to use it. using const would also not work because of the (lax) semantics of const in C. it would, in essence, allow you to poke around with internals that are none of your concern. future releases of gtk+ might even result in a computed Allocation which is not stored by the widget itself - so using an out parameter is the only safe, consistent and future-proof way of returning structures in C. I'm sorry, but that's just life. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
