[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistencies in hello.c

From: Reuben Thomas
Subject: Re: Inconsistencies in hello.c
Date: Sat, 7 Mar 2020 19:11:17 +0000

On Sat, 7 Mar 2020 at 18:50, Roland Illig <address@hidden> wrote:

> Dear Hello developers,

Thanks for writing!

as the German translator of hello, I wondered why there hasn't been a
> release in the last few years.

Inactive maintainers! I handed over to Sami some years ago, and he in turn
has found less and less time to work on hello.

It looks as if some non-GNU developer had added the calls to
> parse_options and strlen and a few others. The code should follow a
> single formatting style.


While here, it looks simply wrong to call mbsrtowcs inside of main. The
> former is a very low-level call, while the latter should provide the
> top-level overview to the reader. That's a violation of abstraction
> layers. Printing a multi-byte string should be extracted into a separate
> function. Since that is not even specific to Hello, it should probably
> be in Gnulib.

I'm unclear why this can't just use wprintf with a %s format specifier.

The comment above the call to setlocale looks entirely redundant to me.


> The comment "Even exiting has subtleties" is probably even more correct
> than intended. What happens if main returns an exit code 7, will that 7
> be shadowed by close_stdout? That would be unexpected since Hello should
> report the error that occurred first.

The comment suggests this behavior is deliberate. However, I agree that it
would be better style to check that writes succeed as they are done.

In the "while ((optc" loop, is it really considered good style to have a
> while loop with such a long body and not use any braces?

Looks fine to me, with the switch directly under the while.

I wonder why the "translation bugs" message is suppressed for English
> locales. Even these can contain typos since the spelling differs for
> some words and phrases.


It's probably time to send the current version
> to the Translation Project. While here, it is not obvious to me where
> the i18n translations are stored. Other projects typically store them in
> the po/ directory, but that directory is essentially empty.

They're stored in the Translation Project AIUI. So, there's no need to send
anything there.

The last entry in po/ChangeLog is from 2011. That looks unrealisticly old.

That's right, the file should probably point to git history for more recent

Patches, or even filed issues in Savannah would be most welcome!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]