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 >
