public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "Keith Packard" <keithp@keithp.com>
To: Dimitrios Glynos <dimitris@census-labs.com>, newlib@sourceware.org
Subject: Re: undefined references since newlib-3.2.0
Date: Mon, 15 Jun 2020 20:43:37 -0700	[thread overview]
Message-ID: <877dw7hdzq.fsf@keithp.com> (raw)
In-Reply-To: <e5b64870-508a-15a5-b1a2-fb5b4ed10d20@census-labs.com>

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Dimitrios Glynos <dimitris@census-labs.com> writes:

> For these reasons, I had proposed for case (b) the introduction of a
> function that would be implemented by the developer, and would handle
> non-reported out-of-memory conditions. Developers already supply
> implementations for system calls on bare bones devices, and this could
> be a similar concept to that.

I'd suggest that this new application-supplied function would be defined
to return normally, and that the library would then return a "safe"
value back to the application to provide a well-defined flow of control
even in this case.

> Finally, it would be beneficial for all if both projects
> (picolibc and newlib) filed a comment to the standards group
> stating the cases where an ENOMEM was found useful but was not
> covered by the standard.

Yeah, fortunately in the default configuration, picolibc doesn't have
any cases like this at this point. In that configuration, picolibc will
only call malloc for operations which already have well defined
out-of-memory behavior (e.g. strdup). It's only if you switch to the
original newlib stdio code that you hit these cases due to the use of
the multi-precision math code in that path.

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2020-06-16  3:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09  8:00 Wolf, Josef
2020-06-12  8:21 ` Josef Wolf
2020-06-12 22:50   ` Josef Wolf
2020-06-13  0:05     ` Keith Packard
2020-06-13  8:27       ` Josef Wolf
2020-06-13 17:20         ` Keith Packard
2020-06-14 14:50           ` Josef Wolf
2020-06-14 17:02             ` Keith Packard
2020-06-14 17:40               ` Brian Inglis
2020-06-14 20:13                 ` Keith Packard
2020-06-15  4:53               ` Dimitrios Glynos
2020-06-16  3:43                 ` Keith Packard [this message]
2020-06-17 11:36           ` Josef Wolf
2020-06-13 10:31     ` Jeffrey Walton

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=877dw7hdzq.fsf@keithp.com \
    --to=keithp@keithp.com \
    --cc=dimitris@census-labs.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).