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.
