public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
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

  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).