[RFC] newlib/libc/include/langinfo.h: nl_langinfo enum off by one error causing pointer overwrite

Corinna Vinschen vinschen@redhat.com
Mon Aug 26 08:42:26 GMT 2024


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



More information about the Newlib mailing list