Re: [RFC] newlib/libc/include/langinfo.h: nl_langinfo enum off by one error causing pointer overwrite
Corinna Vinschen <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On Aug 24 10:54, Brian Inglis wrote: > On 2024-08-23 02:39, Corinna Vinschen wrote: > > No. First of all, apart from fetching LANG from the windows locale > > at startup (see /etc/profile.d/lang.*), the codeset is maintained by > > Cygwin/newlib alone, via LC_* environment and setlocale() calls in > > the application. > > > > Also, Windows has no GetLocaleInfo call for fetching locale-specific > > yes/no strings. I. e., there's no equivalent for LC_MESSAGES. > > > > Therefore Cygwin fetches the information from static information > > maintained in winsup/cygwin/local_includes/lc_msg.h. > > > > If you look closely into __set_lc_messages_from_win(), you'll > > notice that the __get_rfc5646_from_locale() function is called > > from __set_lc_messages_from_win() *only* to check if a matching > > Windows locale exists. This is a pure sanity check. After that, > > any further information is taken from the lc_msg struct defined > > in lc_msg.h, which in turn has been fetched from Linux. See > > winsup/cygwin/linux-locale-helpers. > > > > Does that make sense? > > Yes - I dug into all those sources and that is not any issue. > > But __set_lc_messages_from_win() then adds the codeset field before the wide > character fields, as with the other Cygwin functions, so would it not be > more consistent and simpler to just add an enum entry for the codeset, > called something unique including ...CODESET..., keeping the entry and > realigning tha last few indexes with the items, as nobody else has noticed > any issue in the last 15 years ;^> Again: The values MUST NOT change for backward compat. The order in the nl_item enum doesn't reflect a struct order anyway, because the first items are the standarized ones, and only then the extensions follow with the preference of values already defined with __HAVE_LOCALE_INFO__. Apart from that, the actual numeric values are meaningless. They could have been chosen by throwing a dice. If you feel really strongly about, we can add a comment, like this: diff --git a/newlib/libc/include/langinfo.h b/newlib/libc/include/langinfo.h index 41d090d3710e..509e8fb0e493 100644 --- a/newlib/libc/include/langinfo.h +++ b/newlib/libc/include/langinfo.h @@ -298,6 +298,7 @@ enum _NL_MONETARY_WPOSITIVE_SIGN, _NL_MONETARY_WNEGATIVE_SIGN, + /* _NL_MESSAGES_CODESET already defined earlier for compatibility */ _NL_MESSAGES_WYESEXPR, _NL_MESSAGES_WNOEXPR, _NL_MESSAGES_WYESSTR, Corinna