[PATCH v2] newlib: fix build with <gcc-5 versions
Corinna Vinschen
vinschen@redhat.com
Thu Mar 17 09:49:08 GMT 2022
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.
Corinna
More information about the Newlib
mailing list