> 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 <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
Cheers, Stefan
