Re: [PATCH] bisect: save heap memory. allocate only the required amount

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> The string will always be "dist=" followed by decimal representation of
>> a count that fits in "int" anyway, so I actually think use of strbuf is way
>> overkill (and formatting it twice also is); the patch as posted should be
>> just fine.
>
> I think you are right, and the patch is the right direction (assuming we
> want to do this; I question whether there are enough elements in the
> list for us to care about the size, and if there are, we are probably
> better off storing the int and formatting the strings on the fly).

;-)

> It would be nice if there was some way to abstract the idea of
> formatting a buffer directly into a flex-array. That would involve the
> double-format you mention, but we could use it in lots of places to make
> the code nicer....
> ...
>   struct name_decoration *r = fmt_flex_array(sizeof(*r),
>                                              offsetof(*r, name),
> 					     "dist=%d", x);
>
> which is a little less nice. You could make it nicer with a macro, but
> we don't assume variadic macros. <sigh>

At first I thought "Yuck.  A helper only to format into the flex
member that holds a string?", and I tried to change my mind, but I
couldn't quite convince myself.  At least not yet.

Among the flex arrays we use, some are arrays of bools, some others
are arrays of object names, and there are many arrays of even more
esoteric types.  Only a small number of them are "We want a struct
with a constant string, and we do not want to do two allocations and
to pay an extra dereference cost by using 'const char *'".

For them, by the time we allocate a struct, by definition we should
have sufficient information to compute how large to make that
structure and a printf-format plus its args would be the preferred
form of that "sufficient information", I would think.

The name "fmt_flex_array()", which stresses too much on the
"formatting" side without implying that it is the way to allocate
the thing, may be horrible, and I agree with you that without
variadic macros the end result may not read very well.  Unless we
have great many number of places we can use the helper to make the
code to create these objects look nicer, I am afraid that the
pros-and-cons may not be very favourable.

Thanks for an interesting tangent.