From: "R. Diez" <rdiezmail-newlib@yahoo.de>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: "newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined
Date: Tue, 28 Apr 2020 19:57:55 +0000 (UTC) [thread overview]
Message-ID: <1088500099.3472913.1588103875027@mail.yahoo.com> (raw)
In-Reply-To: <CAOox84vYRMU2K2UE6OasV_PMrkvjBcCD5s7Wxj0eLFSA1gT4Hw@mail.gmail.com>
Hallo again:
After some further research and testing, I wanted to share a couple of hints that may help other people too:
Point 1) Configuring with --disable-newlib-reent-small (which is actually the default) gets rid of the surprising malloc() on first touch from rand(), and probably many other places.
Note that sizeof( struct _reent ) increases from 240 bytes to 1064 bytes (tested with Newlib version 3.3.0).
I think Newlib should document that option --enable-newlib-reent-small is risky. Unless you are really tight on RAM, I strongly advise against this unsafe optimisation.
Point 2) The documentation on this section is misleading:
https://sourceware.org/newlib/libc.html#Reentrancy
That section states:
-----------8<-----------8<-----------8<-----------8<-----------
This means that you have two ways to achieve reentrancy. Both require that each thread of execution control initialize a unique global variable of type ‘struct _reent’:
Use the reentrant versions of the library functions, after initializing a global reentrancy structure for 1. each process. Use the pointer to this structure as the extra argument for all library functions.
-----------8<-----------8<-----------8<-----------8<-----------
This section gives you the impression that you are free to choose. But if you have multithreading, you really need to implement _impure_ptr, mention in option (2). For example, the rand() function needs such a global state (that was my impression by looking at the convoluted macros).
Newlib does have a rand_r() counterpart, but it is not really equivalent (it is a much weaker pseudo-random generator), and Posix has declared it obsolete. So there is no real xxx_r() equivalent for rand() in Newlib (that I could see).
All the best,
rdiez
next prev parent reply other threads:[~2020-04-28 19:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <989180140.2023825.1588003097077.ref@mail.yahoo.com>
2020-04-27 15:58 ` R. Diez
2020-04-27 17:39 ` Jeff Johnston
2020-04-27 20:29 ` R. Diez
2020-04-27 23:57 ` Jeff Johnston
2020-04-28 12:06 ` R. Diez
2020-04-29 19:51 ` Jeff Johnston
2020-04-30 8:08 ` R. Diez
2020-04-28 19:36 ` FAQ link to crossgcc broken R. Diez
2020-04-28 19:57 ` R. Diez [this message]
2020-04-28 22:00 ` _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined Keith Packard
2020-04-29 13:05 ` R. Diez
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=1088500099.3472913.1588103875027@mail.yahoo.com \
--to=rdiezmail-newlib@yahoo.de \
--cc=jjohnstn@redhat.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).