On 17 Mar 2022 10:49, Corinna Vinschen wrote:
> On Mar 16 22:41, Mike Frysinger wrote:
> > On 16 Mar 2022 10:17, R. Diez wrote:
> > > >> Therefore, compiling your code with GCC < 5 will silently break your application.
> > > >> After all, the only reason to use __builtin_mul_overflow() is
> > > >> that you need to check for overflow, is it?
> > > > 
> > > > practically speaking, i don't think this is a big deal.  newlib gained these
> > > > checks only "recently" (<2 years ago).  newlib has been around for much much
> > > > longer, and the world didn't notice.
> > > 
> > > Such general justifications wouldn't pass quality assurance (if we had one).
> > 
> > in your opinion.  software is not perfect, it's trade-offs.
> > 
> > > > yes, if an app starts trying to allocate
> > > > huge amounts of memory such that it triggers 32-bit overflows when calculating,
> > > > the new size, it will probably internally allocate fewer bytes than requested,
> > > > and things will get corrupted.  but like, don't do that :p.  such applications
> > > > probably will have other problems already.
> > > 
> > > You are suggesting that this only affects memory allocation, but the patch is for libc/include/sys/cdefs.h , so those mine traps will be available for everybody.
> > > 
> > > People will tend to assume that anything in Newlib is correct, and code has a way to get copied around and re-used.
> > > 
> > > There are many ways to mitigate the risk:
> > > 
> > > - Require GCC 5.
> > > - Provide a proper implementation of __builtin_mul_overflow().
> > > - Patch all users of __builtin_mul_overflow() within Newlib, so that they do not use it if the compiler does not provide it.
> > > - Issue a compilation warning for GCC < 5 that the "stub" __builtin_mul_overflow() is broken.
> > >    Note that this is not actually a "stub" implementation in the common sense.
> > > - Add an "assert( false ) // fix me" inside the implementation.
> > > - Add a comment stating that the "stub" implementation is not actually correct.
> > 
> > any option that prevents correct execution with gcc-4 is not an improvement.
> > if you care this much, feel free to contribute a patch.  or use gcc-5+ and
> > not worry about it.
> > -mike
> 
> Does anybody actually care for building with gcc < 5?  If not, we
> should just make gcc 5 a prerequisite.

i'm using gcc 4.9 for one of my targets which is why i noticed :).
-mike