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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 17/03/2022 09: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.
> 
> 

It's not just about old GCC, it's about any C compiler that doesn't have 
that builtin.

R.
> Corinna
>