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

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.

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

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

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

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.