> 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 
>> 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.

Reply via email to