Re: fprintf_ln() is slow

From: Jeff King <peff@peff.net>
Date: Jun 27, 2019, 21:26 UTC
Message-ID: <20190627212636.GC20250@sigill.intra.peff.net>
In-Reply-To: <CACsJy8AgmM0xYMMdYvpRSs4JRbNahcQyGcMMfPmaTS4Uv=Ok6A@mail.gmail.com>

On Thu, Jun 27, 2019 at 07:32:53PM +0700, Duy Nguyen wrote:

Show 16 quoted lines

> > It's also not possible for translators to do this by mistake
> 
> This (accidentally dropping \n which sometimes is significant) is the
> part that I made me prefer *printf_ln(). I had been translating for
> years, as far back as 2003-ish, but I've stopped since the last few
> years so I'm no longer uptodate with gettext development. And my very
> old/outdated experience with gettext might make me think it's still
> the problem.
> 
> > without
> > being caught, because msgfmt will catch this (and other common issues):
> >
> >     po/de.po:23: 'msgid' and 'msgstr' entries do not both end with '\n'
> 
> Ok good. And with the downside of degraded performance, sure remove
> all the *printf_ln()

I don't have a strong opinion here. If you want to convert them all back to embedded "\n", that's fine with me.

But I do suspect this same issue will come up in other places, too. For instance, we already format into a buffer for error(), etc. Mostly for atomic output as opposed to efficiency. And it's not just "\n", but adding prefixes, etc.

It might be nice to have some generalized solution for writing to stderr. And maybe it's even just using vreportf more widely. That also caps the output length and munges unprintable characters, but that's probably a good thing when we're going to stderr.

-Peff