You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2019/01/10 00:41:33 UTC
Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4
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.
If we did use the patch below, I suspect we would rather tweak the CPPFLAGS
of only the single module, and not modify the CPPFLAGS of all sources, if
we can avoid that unexpected side-effect.
On Tue, Jan 8, 2019 at 7:12 AM <ji...@apache.org> wrote:
> Author: jim
> Date: Tue Jan 8 13:12:34 2019
> New Revision: 1850745
>
> URL: http://svn.apache.org/viewvc?rev=1850745&view=rev
> Log:
> This just got me. I upgraded macOS to Mojave (w/ latest Xcode) and I
> always build w/ maintainer-mode. The problem is that libxml2 will include
> various unicode/*.h files that have C++ type comments, which causes
> building to fail (due to Werror). Work around this.
>
> Modified:
> httpd/httpd/trunk/modules/filters/config.m4
>
> Modified: httpd/httpd/trunk/modules/filters/config.m4
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/config.m4?rev=1850745&r1=1850744&r2=1850745&view=diff
>
> ==============================================================================
> --- httpd/httpd/trunk/modules/filters/config.m4 (original)
> +++ httpd/httpd/trunk/modules/filters/config.m4 Tue Jan 8 13:12:34 2019
> @@ -114,6 +114,10 @@ AC_DEFUN([FIND_LIBXML2], [
> if test -n "${xml2_path}" ; then
> ac_cv_libxml2=yes
> XML2_INCLUDES="${xml2_path}"
> + dnl libxml2 includes unicode/*.h files which uses C++ comments
> + if test "$GCC" = "yes"; then
> + APACHE_ADD_GCC_CFLAG([-Wno-error=comment])
> + fi
> else
> ac_cv_libxml2=no
> fi
>
>
>
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Dennis Clarke <dc...@blastwave.org>.
On 1/15/19 9:13 AM, Jim Jagielski wrote:
>> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr <wrowe@rowe-clan.net
>> <ma...@rowe-clan.net>> wrote:
>>
> 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.
Any platform that lacks C99 should be ignored. Merely my opinion. Even
worse would be compilers that can not implement C99.
Dennis
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ji...@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 <ru...@vodafone.com> wrote:
>>
>> C2 General
>>
>> > -----Ursprüngliche Nachricht-----
>> > Von: Stefan Eissing <st...@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 <ji...@jagunet.com> wrote:
>> > >
>> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
>> > > >
>> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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
>
Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski <ji...@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.
>
Understood, but you might have overlooked the fact that changing CPPFLAGS
(or CFLAGS - even worse) changes it for the entire build.
My normal config, without your patch;
./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
./build/config_vars.mk:PICFLAGS =
./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
./build/config_vars.mk:CPPFLAGS =
./build/config_vars.mk:CFLAGS =
./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused
./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -pthread
./build/config_vars.mk:INTERNAL_CPPFLAGS =
With your patch in 2.5.x;
./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
./build/config_vars.mk:PICFLAGS =
./build/config_vars.mk:UNITTEST_CFLAGS = -pthread
./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
./build/config_vars.mk:CPPFLAGS =
./build/config_vars.mk:CFLAGS =
./build/config_vars.mk:CFLAGS_FOR_BUILD =
./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused -Wno-error=comment
./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -pthread
./build/config_vars.mk:INTERNAL_CPPFLAGS =
As you can see, you didn't modify only modules/filters/ ... Maybe you
meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
> Anything else seems more disruptive than that. So why are the more
> disruptive changes preferred? I'm just trying to understand the logic there.
>
My thought is that your observation was spot-on that libxml2, but soon
more and more system headers will introduce C99 headers, and there is
no reason to apply just the bandaid, certainly not to the whole server
based on accumulated individual modules/foo/config.m4 bandaids.
That's my objection to the commit in trunk.
If we agree this is a problem to solve, let's not presume libxml2 will
be the end of it, and produce another tarball that gets broken with
maintainer mode in the next OS release of your favorite *nix?
I'm seeing it as inevitable that we should allow all manner of
c99'isms from system headers when we build in our most strict mode,
but when we don't build in maintainer-mode, to leave things at c89
without -Wall etc. I see that as the most flexible compromise, without
suggesting that we *add* c99'isms to httpd itself, just yet.
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Jim Jagielski <ji...@jaguNET.com>.
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.pluem@vodafone.com <ma...@vodafone.com>> wrote:
>
> C2 General
>
> > -----Ursprüngliche Nachricht-----
> > Von: Stefan Eissing <stefan.eissing@greenbytes.de <ma...@greenbytes.de>>
> > Gesendet: Mittwoch, 16. Januar 2019 10:00
> > An: dev@httpd.apache.org <ma...@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 <http://clan.net/>>:
> > >
> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener <covener@gmail.com <ma...@gmail.com>> wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>>
> > wrote:
> > > >>
> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr <wrowe@rowe-clan.net <ma...@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 <http://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
Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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.pluem@vodafone.com> wrote:
>
> C2 General
>
> > -----Ursprüngliche Nachricht-----
> > Von: Stefan Eissing <st...@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 <ji...@jagunet.com> wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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
>
AW: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
C2 General
> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing <st...@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 <ji...@jagunet.com> wrote:
> >
> > > On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
> > >
> > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 16.01.2019 um 03:33 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
> On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
> >
> > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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
Cheers, Stefan
Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
> >
> > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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.
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 15, 2019, at 9:21 AM, Eric Covener <co...@gmail.com> wrote:
>
> On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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.
Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <ji...@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.
Re: svn commit: r1850745 -
/httpd/httpd/trunk/modules/filters/config.m4
Posted by Jim Jagielski <ji...@jaguNET.com>.
> 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 <http://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.