Re: Don't use G_STRLOC

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Mon, 21 Jan 2002, Owen Taylor wrote:
> 
> > Unfortunately, with GCC 3.0 or greater, G_STRLOC is going to have
> > to be only FILE:LINE -- the behavior of __PRETTY_FUNCTION__ is
> > changing in 3.2 and even current versions spew lots of warnings
> > about concetenating use of __PRETTY_FUNCTION__.
> > 
> > (http://bugzilla.gnome.org/show_bug.cgi?id=69097 has some details)
> > 
> > We can conditionalize the use of __PRETTY_FUNCTION__ on GCC version,
> > but soon enough the situation will be:
> > 
> >  G_STRLOC will give FILE:LINE on non GCC systems
> >  G_STRLOC will give FILE:LINE on current GCC systems
> >  G_STRLOC will give FILE:LINE:FUNCTION on old GCC systems
> > 
> > In view of this, I'd suggest that people don't use G_STRLOC,
> > and change:
> > 
> >  g_warning (G_STRLOC "you can't do that!")
> > 
> > to:
> > 
> >  g_warning ("myfunc(): you can't do that!")
> > 
> > or:
> > 
> >  g_warning ("%s:%d:myfunc(): you can't do that!", __FILE__, __LINE__)
> > 
> > If you feel the file/line is important. 
> 
> eek, this renders G_STRLOC pretty unusable, the reason to use it in the first
> place is the bad maintainability of g_warning ("myfunc(): you can't do that!");
> since myfunc() often enough gets renamed or moved without the warning being
> adopted.
> the alternative, something like:
> #define G_LOCFMT  "%s:%s:%s"
> #define	G_LOCARG  __FILE__, __LINE__, __func__
> g_warning (G_LOCFMT ": don't call me", G_LOCARG);
> is way more bug prone and actually quite hackish.

Maybe:

#define G_WARN_LOC (ARGS) \
  g_warn_and_free (g_strdup_printf ARGS, __FILE__, __LINE__, __func__)

So, you can do:

 G_WARN_LOC (("%s failed", something));

[ g_warn_loc ("%s failed", something); is easy to do as long as you don't mind
  it failing back to g_warning() for non-C99 non-GCC compilers ]

> i don't consider G_STRLOC being most usable on gcc systems such a big problem
> though, since the majority of glib users actually develops on gcc systems and
> this macro is a huge help there to improve warning readability.
> so i think it'd be worth at least pointing out the issue to the gcc
> team.

As mentioned in the bug report, the problem is that the GCC team does have a
pretty good excuse for making the change ... according to the C standard,
concatenating strings is supposed to happen _before_ the point where
functions are identified and so forth.

Regards,
                                        Owen