Re: [PATCH v2] newlib: fix build with <gcc-5 versions

["R. Diez" <rdiezmail-newlib@yahoo.de>]

>> 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).


> 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.

Regards,
   rdiez