Re: GLib: G_GNUC_FUNCTION vs. gcc-3.x



Johannes Stezenbach <js convergence de> writes:

> On Wed, Jan 15, 2003 at 04:13:23PM -0500, Owen Taylor wrote:
> > 
> > Johannes Stezenbach <js convergence de> writes:
> > 
> > > What's the reason for not defining G_GNUC_FUNCTION and
> > > G_GNUC_PRETTY_FUNCTION for gcc-3.x?
> > 
> > Look at say, gtk_widget_grab_default()
> > 
> >     g_warning (G_STRLOC ": widget not within a GtkWindow");
> > 
> > __FUNCTION__ in gcc < 3, G_GNUC_FUNCTION, and G_STRLOC token
> > paste.
> > 
> > __FUNCTION__ in gcc >= 3 doesn't. (Or warns that it won't
> > in the future.)
> 
> Ah, OK.
> 
> > The GCC-3.0 behavior for __FUNCTION__ is more compatible with
> > C99 __func__ and easier to implement with a clean 
> > preprocessor/compiler separation, but can't be used for
> > G_GNUC_FUNCTION.
> 
> The documentation of G_GNUC_FUNCTION and G_GNUC_PRETTY_FUNCTION
> does not mention any of this. I have some debug prints that do
> 
> 	g_message ("%s: foobar", G_GNUC_FUNCTION);
> 
> and suddenly are much less informative :-(

Feel free to submit a doc patch.
 
> No problem for me, I can change those. But I suspect other
> people will have the same problem, now that Debian unstable
> has made gcc-3.2.2-pre the default system compiler.

Well, certain distributions have been shipping gcc-3.x as the
stable compiler for a while now...

The right thign to do here is to add a new macro that;

 a) Uses __func__ for C99, so isn't GCC-extension specific

 b) Isn't guaranteed to string concatenate

I've moved http://bugzilla.gnome.org/show_bug.cgi?id=51639 to
the 2.4 API freeze milesteone.

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]