Re: Varargs type stringification (#50972)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 27 Mar 2001, Owen Taylor wrote:
> 
> > 
> > g_strdup_value_contents() is neat, but not all that convenient to 
> > use since:
> > 
> >  - You have to construct a value if you don't 
> 
> don't ... what? 

To fill in the (fairly obvious) blank - if you don't already have
one. The most common cases where this would be useful:

 - To print out an enum value
 - To print out a flags value
 - To print out a GObject pointer with the type

> it strngifies a value's contents, i don't quite understand why you would
> want this to work for non-GValue varargs collected values... ;)

Read the bug report. Basically, the original idea was that
we wanted an easy way to print out an enumeration as a string
for debug purposes.

 G_CONST_RETURN gchar *gtk_enum_get_name (GType enum_type, guint value);

But it seemed to me that it might be better to provide something
more general.
 
> > Here's a patch to add:
> > 
> > gchar*                g_strdup_type             (GType         type,
> > 					         ...);
> 
> erm, "type" appears really odd to me, probably better called
> g_strdup_typed_value(), but before that i'd like to hear some
> rationale for that function.
> 
> > G_CONST_RETURN char * g_stringify_type          (GType         type,
> > 					         ...);
> > 
> > Which do the same thing but with GType + varargs. g_stringfy_type()
> > uses a small ring buffer of static results to make it real easy
> > to use in debug printfs.
> 
> urg, this is a rather cruel hack. while i understand the need for the
> added convenience, we have the same problem (inconvenience) in a couple
> other places as well (the most prominent probably being g_strdup_printf()).

I don't see g_strdup_printf() as being at all parallel.

> i'd rather avoid having ring-buffer variants sprang up for all of them
> during future development and provide something more suitable and scalable
> for long-term use. on why i consider ring-buffer backends not-scalable,
> if functions with ring-buffer backends are called more than ring_size
> times from a function, presumably "constant" strings suddenly become
> invalid. you might want to say that with ring size of e.g. 16, this is
> unlikely to be triggered by code that uses those functions only for
> debugging output, but:
> 
> people don't use your code only for purposes you had in mind, or, more
> conretely, you can't assure g_stringify_typed_value() is only being used
> for debugging output, or only for printfs with less than ring-size
> arguments. especially with setups like:
>   strvalue = g_stringify_typed_value (&my_value);
>   third_party_library_call_that_might_use_g_stringify_typed_value_also ();
>   printf ("%s\n", strvalue);
> users will have to be aware that g_stringify_typed_value() uses a
> ring-buffer backend, i.e. that it doesn't really return a
> G_CONST_RETURN string, and how big the ring buffer is. as soon as
> we add more "convenience" functions to our API that also uses ring buffers,
> preferrable with different sizes even ;) we'll be right on track to win
> the most-confusing-API award.

Well, note that my patch for g_stringify_type() actually had docs with
the appropriate warnings...

I agree that it is somewhat dangerous. I don't see it as leading to
the rack-and-ruin as you seem to see it leading to. After all the C
library has had functions in it that use only a _single_ static buffer
for a long time.

We could call it g_debug_stringify_type() or something like that if
you want the name to more explicitely indicate the use.

Of course, the nice thing to do here would be to be able to insert
typed values as a special format specifier into g_print() /
g_strdup_printf(), but reimplementing printf() is not high on my list
of things to do....

> a good while back i already spent a couple thoughts on getting around
> the need to free certain temporary values (mostly strings) and how to
> provide a suitable g_alloca() implementation for systems where we can't
> use native alloca() for whatever reasons.

Returning result allocated through alloca() is something that you
_really_ should not do. It's not safe at all.

So, I don't see any way (without statement expressions, and not really
even then) of writing something that works inline using alloca. And
once you've given up the ability to write things inline, I think
explicit deallocation is best.

> i think the best approach for both is a stack-level dependant allocator
> that's undergoing frequent release cycles triggered by the main loop.

Sounds scary.

And actually, I don't think using main-loop triggered deallocation is
really safe, since people may write apps that do arbitrary amounts of
operations before returning to the main loop.
 
> i'd like to defer discussion about such allocators a bit though, say
> untill next week, where we hopefully have a chance to dicuss that in person.

A post 2.0 thing, I believe.
                                        Owen