public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: newlib@sourceware.org
Subject: Re: Problem with recent change to getlocalename_l
Date: Thu, 1 Feb 2024 20:00:02 +0100	[thread overview]
Message-ID: <ZbvqMlj3-1w3KaDb@calimero.vinschen.de> (raw)
In-Reply-To: <b907b4b8-1383-4dfc-a336-5933391ed9b7@gmail.com>

Hi Jeff,

[please do not cc me, I'm reading the mailing list all the time.  Thanks!]

On Feb  1 09:39, Jeff Law wrote:
> 
> We're seeing a few ports fail to build newlib after this change:
> 
> > commit 71511d4ac8686c2220093cc01525311d9c88bc4e
> > Author: Corinna Vinschen <corinna@vinschen.de>
> > Date:   Sun Jan 21 13:23:09 2024 +0100
> > 
> >     getlocalename_l: implement per SUS Base Specifications Issue 8 draft
> >       #include <locale.h>
> >       const char *getlocalename_l(int category, locale_t locobj);
> >     Most notably, we need a per-thread space to store the string
> >     returned if locobj is LC_GLOBAL_LOCALE.  No errors are defined
> >     for getlocalename_l.  So we can't use buffer allocation which
> >     might lead to an ENOMEM error.  We have to use a "static" buffer
> >     in the per-thread state.
> >     Note that the feature test macro in locale.h is not quite correct.
> >     This needs to be fixed as soon as the
> 
> pru-elf shows this failure:
> 
>  CC       libc/stdlib/libc_a-btowc.o
> In file included from
> /home/jlaw/test/newlib-cygwin/newlib/libc/include/wchar.h:6,
>                  from
> /home/jlaw/test/newlib-cygwin/newlib/libc/stdlib/btowc.c:1:
> /home/jlaw/test/newlib-cygwin/newlib/libc/stdlib/btowc.c: In function
> 'btowc':
> /home/jlaw/test/newlib-cygwin/newlib/libc/stdlib/btowc.c:24:3: error:
> 'struct _misc_reent' has no member named '_getlocale_l_buf'
>    24 |   _REENT_CHECK_MISC(_REENT);
>       |   ^~~~~~~~~~~~~~~~~
> 
> The tester is also seeing xstormy16-elf and msp430-elf fail in the same
> manner.

Given that this new functionality needs a 32 byte buffer, and given that
_REENT_SMALL targets are... well... small, I made the new buffer
optional via `#ifdef _MB_CAPABLE' in struct _misc_reent, which only used
by _REENT_SMALL targets.

Apparently I missed to take the _REENT_CHECK_MISC expression into account.
AFAICS the culprit is the _REENT_INIT_MISC macro now.

Can you please check if this change fixes the problem?

diff --git a/newlib/libc/include/sys/reent.h b/newlib/libc/include/sys/reent.h
index 4e60c3096ae2..caf554b9c26a 100644
--- a/newlib/libc/include/sys/reent.h
+++ b/newlib/libc/include/sys/reent.h
@@ -514,7 +514,7 @@ struct _reent
 #define _REENT_CHECK_EMERGENCY(var) \
   _REENT_CHECK(var, _emergency, char *, _REENT_EMERGENCY_SIZE, /* nothing */)
 
-#define _REENT_INIT_MISC(var) do { \
+#define __REENT_INIT_MISC(var) do { \
   struct _reent *_r = (var); \
   _r->_misc->_strtok_last = _NULL; \
   _r->_misc->_mblen_state.__count = 0; \
@@ -533,10 +533,18 @@ struct _reent
   _r->_misc->_wcrtomb_state.__value.__wch = 0; \
   _r->_misc->_wcsrtombs_state.__count = 0; \
   _r->_misc->_wcsrtombs_state.__value.__wch = 0; \
-  _r->_misc->_getlocale_l_buf[0] = '\0'; \
   _r->_misc->_l64a_buf[0] = '\0'; \
   _r->_misc->_getdate_err = 0; \
 } while (0)
+#ifdef _MB_CAPABLE
+#define _REENT_INIT_MISC(var) do { \
+  struct _reent *_r = (var); \
+  __REENT_INIT_MISC(_r) \
+  _r->_misc->_getlocale_l_buf[0] = '\0'; \
+} while (0)
+#else
+#define _REENT_INIT_MISC(var) __REENT_INIT_MISC(var)
+#endif
 #define _REENT_CHECK_MISC(var) \
   _REENT_CHECK(var, _misc, struct _misc_reent *, sizeof *((var)->_misc), _REENT_INIT_MISC(var))
 
Thanks,
Corinna


  reply	other threads:[~2024-02-01 19:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01 16:39 Jeff Law
2024-02-01 19:00 ` Corinna Vinschen [this message]
2024-02-01 19:11   ` Corinna Vinschen
2024-02-01 19:44     ` Corinna Vinschen
2024-02-04 19:34       ` Dimitar Dimitrov
2024-02-05  2:39         ` Jeff Law
2024-02-05  9:39           ` Corinna Vinschen
2024-02-01 20:55     ` Torbjorn SVENSSON
2024-02-01 21:55       ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZbvqMlj3-1w3KaDb@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).