Re: vsnprintf unnecessarily configures and builds vasnprintf.o etc.

[Paul Eggert]

On 04/07/2011 03:02 AM, Bruno Haible wrote:
> Maybe if you present
> a complete patch for the vasnprintf case, it will show in the daylight how
> gnulib-tool should perform this extended dependency tracking?

Thanks for your comments.  I'll think about this, but in the meantime
I've discovered that one of the Emacs places that uses vsnprintf
should really use vasnprintf, because it might generate a string longer
than INT_MAX.  Since Emacs will need vasnprintf anyway, the priority
of the extended-dependency-tracking project will be lowered.

But that raises another problem.  For Emacs, I'd like a variant of
vasnprintf that uses Emacs's allocators rather than malloc/realloc/free.
I could instead attack the problem by blocking interrupts while
calling vasnprintf, but I'd rather not add these extra system calls
for every call to vasnprintf.

I expect that I can do that by creating a new module (vcasnprintf, say),
which defines a function that acts like vasnprintf but allocates
storage as specified by a struct allocator parameter.  The best way
to do that, I expect, would be to refactor vasnprintf.c, and I am
thinking of proposing something along those lines.