[PATCH v19 03/11] argp: document translated names in --help and --usage

[Adhemerval Zanella Netto]

On 16/01/26 19:26, Vivien Kraus wrote:
> Hello!
> 
> Le 16/01/2026 à 20:56, Adhemerval Zanella Netto a écrit :
>> Different than other argp interface, like argp_parse, where we can return ENOMEM
>> this is called from __argp_help and can not fail.
>>
>> I am not sure if it would be better to just assert any memory allocation falure
>> like other usage in such cases. Thoughts?
> 
> From what I gather from pgettext_expr, when malloc fails, it allows itself to continue as if no translation was available. This is not documented either.
> 
> The impact here is that instead of reading in the help output: " -c, --colour=COLOUR (--color)", you would read: "  -c, --color=COLOUR", which is harmless (--colour would still be recognized---unless gettext takes some other "cannot allocate means no translation" shortcuts).
> 
> I don't understand whether that is something you want to avoid or not, but I can also just abort. If malloc cannot allocate "command-line option^vcolor", then I doubt there's anything useful that can be computed past that point anyway. I was under the impression that assert(p) was not best practices because if you disable asserts then you also don't check p, but if it's common usage in argp I don't have a problem with it.

Sorry if I was assertive, it is because I am not sure either.  The argp interface
seems be designed solely for program startup, without much failure mode in mind.

But I think the current approach is fine, where is memory allocation fails we also
fail to translate since at this point we can *not* return an error to users (I
think it is better than abort and assert)