[neomutt-devel] [PATCH] add -Werror and -pedantic build flag; fix warnings

[Stuart Henderson]

On 2021/03/06 14:25, toogley wrote:
> On Sat, Mar 06, 2021 at 12:23:09PM +0000, Richard Russon wrote:
> > > I'm sorry for the additional work i'm creating here but i have trouble
> > > configuring/authentificating my github so i can't send a pull request.
> > 
> > > -CFLAGS=		@CPPFLAGS@ @CFLAGS@ -I. -I at srcdir@ -Wall $(EXTRA_CFLAGS)
> > > +CFLAGS=		@CPPFLAGS@ @CFLAGS@ -I. -I at srcdir@ -Werror -pedantic -Wall $(EXTRA_CFLAGS)
> > 
> > Locally, I always build with `-Werror -pedantic` enabled,
> > but this is changing the build for everyone...
> > 
> > whatever their architecture, OS, compiler, compiler version.
> > 
> > I don't want to cause build failures that might only get discovered when
> > packagers try to build NeoMutt after a release.

As a packager, thanks for being aware of this, this is a real problem
that packagers run into with some software, especially on less-used
architectures, maybe with older compilers.

> So basically the idea is to improve the continuous integration by
> forcing errors to be fixed. So for instance, i was also thinking about
> introducing in some months/years ASAN to neomutt's CI so memory bugs are
> more exposed. For instance, i have been running locally with ASAN
> enabled for some weeks and continuously receive many memory leaks.
> However i wanted to look into fixing these memory leaks when i have time
> in the next monhts/years before enabling it in CI.
> 
> I thought making CI stricter (for instance also enabling
> -fsanitize=undefined, -fcf-protection=full -fstack-protector-strong
> -fstack-clash-protection and such things (the above were only the
> beginning of that), issues like these here could be easier to fix by
> making neomutt more deterministic by hard-failing if something's wrong:

Sounds like maybe you're looking for different flags for CI builds than
regular builds?

> https://github.com/neomutt/neomutt/issues/2769

btw for this one, be aware how OpenBSD's malloc works, it mmaps/unmaps
(not all the time, there's a cache, but quite often) so some memory
handling errors that might not be noticed with other mallocs will be
more likely to trigger segv/bus errors. More details about how it works
in https://man.openbsd.org/malloc.