You're correct that popt does not use wcslen().

Hmmm, any suggestions for a CLI executable to try
   LANG=cy_CY foo --help
testing? That appears not to be system-config-date.

I don't have a handy cy_GB.UTF-8 one for testing. I'll ask Dafydd for
suggestions.

Test case courtesy of Telsa

LANG=cy_GB.UTF-8 gnome-terminal

and look at the entry

"--screen=SGRÎN"

Thanks Telsa.

What is failure case? Alignment looks OK (as I would expect from
utf-8). I do not see SGRIN rendered properly. That's the failure?

Stick the terminal you are running it in into UTF8 first and you
should see the SGRÎN rendered correctly and the position now wrong. If
your terminal is in an old 8bit mode it'll render the UTF8 multibyte
symbol as 2 chars so hide the real bug

Thanks for confirm. Now to see if I can
get this bug pasted against popt so I can find

Hmmm, some cures are worse than the disease, I feel a twinge
of BCE tickling my brain stem:

OK, I have display width calculated independently of strlen by doing
(per info libc):

    /* XXX Calculate no. of display characters. */
    if (argDescrip) {
        const char * scopy = argDescrip;
        mbstate_t t;
                                                                     
          
        memset (&t, '\0', sizeof (t));  /* In initial state.  */
        /* Determine number of characters.  */
        len += sizeof("=")-1;
        len += mbsrtowcs (NULL, &scopy, strlen(scopy), &t);
    }

This does not catch the different display size of the SGRIN string
(but does fire on a different case). To be specific, mbsrtowcs and
strlen are returning identical values.

So is there a chance that the display size table for those
multi-byte cy_GB.UTF-8 characters might be wrong?

Hmmm, --screen (and also the other case, --role) now
align. In CVS, should be in popt-1.8.2-0.9 and later.