On 01/05/2012 09:20 PM, Paul Smith wrote:
> What I mean is, instead of voutputf() invoking multiple calls to
> fprintf(), we'd need to compute all the strings we needed then invoke a
> single fprintf() for each output style where the format string was
> translated, something like this:
>
> if (flocp && flocp->filenm)
> fprintf (target, _("%s:%lu: %s%s"), flocp->filenm, flocp->lineno,
> catchy, output);
> else if (makelevel == 0)
> fprintf (target, _("%s: %s%s"), program, catchy, output);
>
> etc. Of course we'd need to use vsprintf() or something to turn the
> va_list into the "output" string. Now a translator can take that format
> string and convert it so that things are generated in a different order
> if necessary.
Function vsnprintf could be used to fill variable "output".
Quoting the local printf(3) man page:
[..]
int vsnprintf(char *str, size_t size, const char *format, va_list ap);
[..]
Feature Test Macro Requirements for glibc
(see feature_test_macros(7)):
snprintf(), vsnprintf():
_BSD_SOURCE || _XOPEN_SOURCE >= 500 || _ISOC99_SOURCE \
|| _POSIX_C_SOURCE >= 200112L;
or cc -std=c99
Is use of that function acceptable?
> The other thing I wonder about is the hardcoding of ASCII colorized
> strings
There have to be defaults somewhere in there. Or not?
> and the start/stop character strings (\033[...). Are there
> other methods of colorizing?
As of now I don't know any other.
> Should we try to support them? Maybe it's
> not worthwhile to try to support generic methods when we have no idea if
> they're useful. We can always make changes needed to support them
> later.
Thanks.
Best,
Sebastian
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
