From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id 40B0E3851C13 for ; Tue, 16 Jun 2020 03:43:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 40B0E3851C13 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id AF1D83F2C90D; Mon, 15 Jun 2020 20:43:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tyvL5d3twezb; Mon, 15 Jun 2020 20:43:40 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id F126B3F2C90C; Mon, 15 Jun 2020 20:43:39 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id C0A621582167; Mon, 15 Jun 2020 20:43:37 -0700 (PDT) From: "Keith Packard" To: Dimitrios Glynos , newlib@sourceware.org Subject: Re: undefined references since newlib-3.2.0 In-Reply-To: References: <87pna2hog9.fsf@keithp.com> <20200614145006.GG15174@raven.inka.de> <87k109h96z.fsf@keithp.com> Date: Mon, 15 Jun 2020 20:43:37 -0700 Message-ID: <877dw7hdzq.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 03:43:44 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dimitrios Glynos 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. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl7oP+kACgkQ2yIaaQAA ABEIZg/9GhVFr8uVufYLl3tiEGzb+ihMcm1A9jj/BT6QndnJ9yCgk1gHs/gl7c2t LZxO/pKhDcvHujzP34TTAX4paQmJASHbevWBCtu0MSQWDlk88hKe/j96nbJaKbfe QbZYN9waTzdSrE/ZOEF9EMCNzLUx+iCwd1JZitYAwva3qbGlRDWiGlAL8rfJIr70 1wFPrVQZ3ExNQKQrf9+fQugOJG9Hho/UZiqXpb5FP+t+zRy1FwQOxCdo+b/GpL31 xllSkG2ER5qMdpSQH4z3K/3263TPlJz3sUP0835fwzmKczD95eZJ0fi/wXB8s5Lt JkDEUzUsow6sTTI2ZlysorqKKoMhSDCACjYOti4UhjjqdAC/R80Dtdtck8pLB4ZJ Wg+rTO3OdGGEGjtXPt2RQ+Y4OgwLVbYwErvWc4wGGbagEft2+5/Yr93puF4+exAf tbYc6uU1kq2qj5eWf4Uh11qodZm/GoZi26ghfBUKEIBFuqYa3XIwkTf24UcJv4Fe LUwdpjVIHBVqcLxUygA9YW1TOAciWR4l3ah6KZtW/eh7nSet112QAA6DYvrhESN/ OQZQGrA9xWXRNB8QDyanhIxEh14Y0U4lKF1ICg8nC/jmRGPA2ZYK5Azpihs1u2sH v7txQ0G34IdVk65rx/J7GlWCWmQGqeokTI+02ot3IfJE1DUU47E= =F++g -----END PGP SIGNATURE----- --=-=-=--