From: "R. Diez" <rdiezmail-newlib@yahoo.de>
To: Corinna Vinschen <vinschen@redhat.com>,
Mike Frysinger <vapier@gentoo.org>,
Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
Cc: newlib@sourceware.org, sebastian.huber@embedded-brains.de
Subject: Re: [PATCH v2] newlib: fix build with <gcc-5 versions
Date: Fri, 18 Mar 2022 09:30:03 +0100 [thread overview]
Message-ID: <18777f5b-7e27-b0a0-5d8f-8ca0a30e07a6@yahoo.de> (raw)
In-Reply-To: <YjQznc4TN9XOilhg@calimero.vinschen.de>
>> It's not just about old GCC, it's about any C compiler that doesn't have
>> that builtin.
>
> Well, I guess, GTG then.
Let's see if I understand the situation:
You are committing a replacement implementation of __builtin_mul_overflow() for older GCC versions and for any other compiler which does not have it.
The only significant extra feature about that function is the detection of integer overflow.
The implementation lives in libc/include/sys/cdefs.h , so it is accessible not just by some special malloc code which should never overflow because targets wouldn't have that much memory or whatever.
The replacement implementation is known to be broken and therefore poses a risk on anybody relying on the original, documented behaviour.
There are no mitigation measures. There is not even a comment next to the replacement implementation that states it is broken.
And you guys are fine with that.
Is that correct?
Regards,
rdiez
next prev parent reply other threads:[~2022-03-18 8:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 3:25 [PATCH] " Mike Frysinger
2022-03-14 7:36 ` Sebastian Huber
2022-03-14 16:58 ` Mike Frysinger
2022-03-15 3:25 ` [PATCH v2] " Mike Frysinger
2022-03-15 12:41 ` Richard Earnshaw
2022-03-15 23:54 ` Mike Frysinger
2022-03-16 7:12 ` R. Diez
2022-03-16 8:30 ` Mike Frysinger
2022-03-16 9:17 ` R. Diez
2022-03-17 2:41 ` Mike Frysinger
2022-03-17 9:49 ` Corinna Vinschen
2022-03-17 11:26 ` Richard Earnshaw
2022-03-18 7:24 ` Corinna Vinschen
2022-03-18 8:30 ` R. Diez [this message]
2022-03-18 9:26 ` Corinna Vinschen
2022-03-18 9:45 ` R. Diez
2022-03-20 1:22 ` Mike Frysinger
2022-03-20 1:21 ` Mike Frysinger
2022-03-20 13:57 ` Jordi Sanfeliu
2022-03-20 12:52 ` Eric Bresie
2022-03-20 14:16 ` Mike Frysinger
2022-03-15 23:53 ` [PATCH v3] " Mike Frysinger
[not found] <1647792834.2524.0.ref@smtp.mail.att.net>
2022-03-20 16:13 ` [PATCH v2] " Steven J Abner
[not found] <1647807849.2524.1.ref@smtp.mail.att.net>
2022-03-20 20:24 ` Steven J Abner
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=18777f5b-7e27-b0a0-5d8f-8ca0a30e07a6@yahoo.de \
--to=rdiezmail-newlib@yahoo.de \
--cc=Richard.Earnshaw@foss.arm.com \
--cc=newlib@sourceware.org \
--cc=sebastian.huber@embedded-brains.de \
--cc=vapier@gentoo.org \
--cc=vinschen@redhat.com \
/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).