Comment 5 for bug 1577460

I've tried (in vain so far) to understand what's going on and how this is related to the locale-langpack/ search path patch.

Tested/reproduced with

  LC_ALL=fo_FOO gdb --args getopt -o c:d:ko:r:v -n /usr/sbin/mkinitramfs -- --help

Some observations:

 * This crash doesn't happen with looking up LC_MESSAGES, only in this getopt case with LC_IDENTIFICATION. The mere presence of /usr/lib/locale/fo_FOO/LC_IDENTIFICATION in the search path causes this crash. If *only* /usr/lib/locale/fo/LC_IDENTIFICATION gets added (and not also the more specific fo_FOO one) then things still work.

 * In all cases the returned list from _nl_make_l10nflist() was correct in memory, so I suppose this triggers some bug (insufficiently large buffer or so) somewhere else. Nevertheless we need to be bug compatible with that.

During that I also noticed some bugs in the patch:

     malloc (sizeof (*retval) + (__argz_count (dirlist, dirlist_len)
- * (1 << pop (mask))
+ * 2 * (1 << pop (mask))

We shouldn't allocate 2* the number here, just argz_count() + 1, as we are only adding one more search path.

Also we should correctly interleave lookups in /usr/share/locale-langpack/ with /usr/share/locale wrt. the mask -- i. e. we should *first* check if there is a more specific locale (with territory, encoding, etc.) in /usr/share/locale-langpack/ and then check more generic locales in both places.

But if I just fix these two bugs, then getopt still crashes on getting too many LC_IDENTIFICATION search paths. So one proposal would be to only do the locale-langpack/ lookup for LC_MESSAGES, not for any other category; our langpacks only ship LC_MESSAGES anyway, so we make the scope of this small enough to avoid triggering the crash.