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