Re: [PATCH v22 0/9] Support translated long option names in getopt and argp

Hello,

Congratulations for glibc 2.44!

Thank you Adhemerval Zanella Netto for your valuable feedback, and the
time you invested.

First, regarding pgettext_expr, the situation is mentioned by Bruno
Haible here:

    https://sourceware.org/pipermail/libc-alpha/2025-May/166977.html

I’m not sure how to move forward. Translations of such short names
would not work great without a context. This is why I added a default
implementation.

Le mercredi 05 août 2026 à 09:42 -0300, Adhemerval Zanella Netto a
écrit :
> 
> 
> On 23/04/26 13:03, Vivien Kraus wrote:
> > Dear glibc developers,
> > 
> > Since there is a new libc.abilist, here is an updated series.
> > 
> > Best regards,
> > 
> > Vivien
> 
> 
> I added some comments on this new version, however before moving one
> I would like
> to have some discussion on the design before sending a new version:
> 
> * The argp now hardcodes 'optctxt = "command-line option"' for every
> argp program, 
>   and because the __translation_collisions_checked flag is per-
> _getopt_data, 
>   it is now a quadratic collision scan.  This is an asprintf +
> dcgettext + free 
>   per pair, issuing the inner option 'n' times.
> 
>   This runs on every argp_parse call of every existing argp program,
> translations
>   or not. I think it would be good to at least add some kinfd of
> cache, and/or
>   skip the scan when the process has no message catalogs, and
> consider making 
>   argp opt-in like getopt_long.
Would it be OK with new argp flags: 

    ARGP_TRANSLATE_OPTIONS = 0x0080

    ARGP_NO_TRANSLATION_CHECK = 0x0100 (or ARGP_CHECK_TRANSLATIONS if
checking is opt-in once translations are enabled)

Maybe adding a new function, if it’s important for argp users to choose
their translation context and domain once they enable translations:

    error_t argp_parse2 (const struct argp *argp, int argc, char
**argv, unsigned flags, int *arg_index, const char *optctxt, const char
*opttextdomain, void *input);

> 
> * On a translator mistake, the first getopt_long call returns '?'
> with a message.
>   This makes the program unusable in that locale even when invoked
> with untranslated
>   names only, and the caller's own "unknown option" handling prints a
> confusing 
>   usage error.  This behavior effectively lets a bad .mo DoS the
> program, which
>   will be only catch on the language is used.
Would you prefer if collisions were reported as they occur in the
getopt_long invocation? It makes it harder for the translator to check
their translations against options they don’t know. But maybe we could
advise the developer to run a full option translation check during the
handling of --help for instance.

Would you rather just have warning messages in stderr or an explicit
failure to match the argument?

> 
> * optctxt / opttextdomain are process-wide mutable state and enabling
> translations
>   in main() changes getopt_long behavior for any library in the
> process that parses
>   options. The getopt family is documented MT-unsafe but this adds
> heap-owned
>   globals freed by 'disable'.
> 
>   I think kind of API as past the date to be included in glibc, they
> are fragile
>   and potentially causes a lot of problems due misuse.
What would you think of a new function instead:

    int getopt_long2 (int argc, char **argv, const char *shortopts,
const struct option *longopts, int *longind, unsigned flags, const char
*optctxt, const char *opttextdomain);

Maybe with these flags: GETOPT_LONG_ONLY, GETOPT_TRANSLATE_OPTIONS,
GETOPT_NO_TRANSLATION_CHECK / GETOPT_CHECK_TRANSLATIONS (depending on
wether checks are on by default).

Or would you rather have different functions for long options, long
options only, translated long options, translated long options only?

I know that gnulib is also trying to improve the getopt_long API. I
don’t want to make future evolutions harder.

> 
> * An accidental double/leading/trailing space in a msgstr produces an
> empty list
>   item, and an empty item exact-matches the empty option name in --
> =value.
I’m not enthusiastic about multiple translations. It would probably be
wise to ignore empty translations entirely though, whether we keep the
multiple translations feature or not.

> 
> And more and more unsure about adding this feature, it seems to add a
> *lot*
> of corner cases and maintainability burden with a very fragile API. 
> I am not
> sure I will have time to continue purse this.
> 
> I don't recall, but did we already checked what is preventing us to
> add this
> feature on gnulibc argv module first? Is is some missing glibc
> support? Maybe
> we can focus on providing the missing knobs instead.
What is "gnulibc argv"?

Since there are many libraries wrapping calls to getopt_long by
generating their own array of struct options, it would be difficult to
ask every one of them to duplicate and translate their generated struct
options[] before calling getopt_long. It would also be more confusing,
since multiple struct option would refer to the same option. It would
be better for glibc’s getopt_long to recognize option translations.

Ideally, the getopt-long wrappers would not need to change anything for
program developers to opt in to the option translations. This is why I
tried global variables first. Having a new getopt_long-like function
(with extra parameters) requires a little adaptation, but not much if
it’s identical to the non-translating getopt_long by default.

What do you think?

Best regards,
Vivien