Re: Broken interactive rebase text after some UTF-8 characters

From: Michal Nowak <mnowak@startmail.com>
Date: Feb 1, 2019, 09:06 UTC
Message-ID: <747726ae27ff52509f831c9615f2b102.startmail@startmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.1902010835210.41@tvgsbejvaqbjf.bet>

Johannes,

On Friday, February 1, 2019 at 8:38 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 28 quoted lines

> Hi,
> 
> On Thu, 31 Jan 2019, Junio C Hamano wrote:
> 
>> Phillip Wood <phillip.wood@talktalk.net> writes:
>>
>> >> Are we misusing C formats?
>> >
>> > The C standard and POSIX both say that the * refers to the maximum
>> > number of bytes to print but it looks like it is being treated as the
>> > maximum number of characters on OpenIndiana.
>> >
>> > Johannes - Perhaps we should change it to use fwrite() unless
>> printf()
>> > gets fixed and we're sure no other operating systems are affected?
>>
>> Avoid such a rewrite, as "%*.s" that takes (int, char *) are used in
>> many other places in our codebase, if you can.
> 
> Yes, this would be painful in particular in cases like
> 
> 	master:advice.c:101:           fprintf(stderr, _("%shint: %.*s%s\n"),
> 
> where we want to write more than just a variable-length buffer.
> 
> I am curious: is libintl (gettext) used on OpenIndiana? I ask because
> AFAIR fprintf() is overridden in that case, and the bug might be a lot
> easier to fix if it is in libintl rather than in libc.

here you can see the full output of the OpenIndiana git build: https://hipster.openindiana.org/logs/oi-userland/latest/git.publish.log.

From what I see there, libintl was found.

If you believe this is illumos libc bug, it would be cool if someone created an simple testcase, which I can forward to the illumos developers.

Thanks, Michal

Show 8 quoted lines

> 
> Of course, it might *still* be a bug in libc by virtue of handing '%.*s'
> through to libc's implementation.
> 
> Alban, can you test this with NO_GETTEXT?
> 
> Thanks,
> Johannes