I specifically didn't use  #pragma GCC diagnostic push
in order to avoid this exact kind of discussion...

> On Jan 16, 2019, at 4:46 PM, Jim Jagielski <j...@jagunet.com> wrote:
> 
> I'm sorry but I'm confused. The patch is as specific as you can get. It just 
> adds the minimal option and JUST for filters and JUST if libxml2 is part of 
> the build. Anything else seems more disruptive than that. So why are the more 
> disruptive changes preferred? I'm just trying to understand the logic there.
> 
>> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> 
>> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
>> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
>> in maintainer mode, or simply switch to -std=c99 presuming that more 
>> and more of the system headers follow c99 syntax over time. 
>> And revert the tweak of modules/filters/config.m4.
>> 
>> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
>> <ruediger.pl...@vodafone.com> wrote:
>> 
>> C2 General
>> 
>> > -----Ursprüngliche Nachricht-----
>> > Von: Stefan Eissing <stefan.eiss...@greenbytes.de>
>> > Gesendet: Mittwoch, 16. Januar 2019 10:00
>> > An: dev@httpd.apache.org
>> > Betreff: Re: svn commit: r1850745 -
>> > /httpd/httpd/trunk/modules/filters/config.m4
>> > 
>> > 
>> > 
>> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr <wrowe@rowe-
>> > clan.net>:
>> > >
>> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski <j...@jagunet.com> wrote:
>> > >
>> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener <cove...@gmail.com> wrote:
>> > > >
>> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <j...@jagunet.com>
>> > wrote:
>> > > >>
>> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr <wr...@rowe-clan.net>
>> > wrote:
>> > > >>
>> > > >> Hi Jim,
>> > > >>
>> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
>> > building on the Fedora 29, largely frozen end-of-july. Reverting the
>> > patch below and toggling -std=c89 to -std=c99 in configure.in building
>> > all but two modules from trunk is building clean, and results in this
>> > command for error checking;
>> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
>> > pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
>> > -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
>> > Wformat -Wformat-security -Wunused     -DLINUX -D_REENTRANT -
>> > D_GNU_SOURCE -DAP_DEBUG
>> > > >>
>> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
>> > not suggesting we change the general builds from c89 in the 2.4 branch,
>> > but that is something we might want to consider for trunk, 20 years out.
>> > > >>
>> > > >>
>> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
>> > considering that we are in 2019 already :)
>> > > >>
>> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
>> > anyway.
>> > > >
>> > > > As a binary distributor, even though a C99 compiler may be available
>> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
>> > > > 2.4.
>> > >
>> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
>> > :)
>> > >
>> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
>> > c89) possibly more difficult. This is either a good thing or a bad
>> > thing. So far, however, iirc we have not had any issues sticking with
>> > c89 and I don't think the above would warrant such a change. IMO of
>> > course.
>> > >
>> > > I might not have been clear, above. I'm not suggesting changing things
>> > for the
>> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
>> > think we should
>> > > have this discussion of when we will begin accepting c99 source
>> > patches, but
>> > > that isn't the immediate problem you've tripped over.
>> > >
>> > > I see several options;
>> > >
>> > >   Only for maintainer mode, where we are strictly handling all errors,
>> > always
>> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
>> > may arise.)
>> > >   All the system headers using c99 (or earlier) semantics should
>> > behave well.
>> > >
>> > >   Or, for maintainer mode, always relax the comments restriction only
>> > so we
>> > >   have -std=c89 -Werror -Wall -Wno-error=comment (but not modified in
>> > the
>> > >   modules/filters/config.m4 where it isn't apparent who toggled this.)
>> > You can
>> > >   almost call this c99-lite which solves one c99'ism in newer system
>> > headers
>> > >   without allowing all the c99'isms in system headers.
>> > >
>> > >   Or, staying closest to the proposed patch, add -Wno-error=comment
>> > only
>> > >   to mod_proxy_html's CPPFLAGS, and stop messing with the rest of the
>> > >   compilation for a single module.
>> > >
>> > > In every case, I'm expecting we still adhere to c89, especially in
>> > httpd-2.4
>> > > branch. A typical compilation (non-maintainer-mode) should catch most
>> > > of those irregularities.
>> > 
>> > My pov:
>> > - as long as 2.4.x is our only release branch, I'd like trunk maintainer
>> > mode to stay compatible
>> > - I would like to switch to c99 as soon as 2.6.0 is out
>> > - The CPPFLAGS switch for the module only seems to be the least
>> > intrusive
>> 
>> Sounds sensible.
>> 
>> Regards
>> 
>> Rüdiger
> 

Reply via email to