bug-hello
[Top][All Lists]
Advanced

[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.
>

Agreed!

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.
>

Agreed.


> 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.
>

Agreed.

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
changes.

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

-- 
https://rrt.sc3d.org


reply via email to

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