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