Re: Showstoppers to 1.7.0?

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 6:37 PM Gregg Smith wrote: > > testencode doesn't want to compile on Visual Studio. > A showstopper maybe not but it is nice to run the tests to compare with > previous versions. > > abts.c > testencode.c > testencode.c(91): error C2059: syntax error: '}' >

Re: Showstoppers to 1.7.0?

2019-03-22 Thread Gregg Smith
testencode doesn't want to compile on Visual Studio. A showstopper maybe not but it is nice to run the tests to compare with previous versions. abts.c testencode.c testencode.c(91): error C2059: syntax error: '}' testencode.c(206): error C2059: syntax error: '}' testencode.c(416): error C2059:

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 6:31 PM William A Rowe Jr wrote: > > This was the fix required for APR_TRY_COMPILE_NO_WARNING... likely a function > you started calling needs a similar fix, which restored the environment in > time for the action-if-true / action-if-false to both behave without an >

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

2019-03-22 Thread William A Rowe Jr
This was the fix required for APR_TRY_COMPILE_NO_WARNING... likely a function you started calling needs a similar fix, which restored the environment in time for the action-if-true / action-if-false to both behave without an unusual environment. --- apr/apr/branches/1.7.x/build/apr_common.m4

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

2019-03-22 Thread William A Rowe Jr
Doesn't make sense, that would be a noop (unless $apr_cvname is used in the true/false condition). Somewhere you nested something oddly. I worked around nesting with my last patch to this logic for the purpose of this specific macro, but in many other autoconf cases, true/false (as we used to do)

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 4:28 PM William A Rowe Jr wrote: > +checking whether int64_t and int use fmt %d... checking whether int64_t and > long use fmt %ld... yes > +no "yes" for %ld and "no" for %d, in stack order? Possibly it would print better with: Index: build/apr_common.m4

Re: svn commit: r1856042 - in /apr/apr/trunk: build/apr_common.m4 configure.in include/apr.h.in

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 12:38 PM William A Rowe Jr wrote: > > > On Wed, Oct 10, 2012 at 9:34 PM, Richard Smith <[hidden email]> wrote: > > > > > > However, glibc's inttypes.h only provides them in C++ mode if > > > _STDC_FORMAT_MACROS is defined, and libc++ doesn't define it. > > > > Sorry,

Re: Verifying printf() formatting of types

2019-03-22 Thread William A Rowe Jr
On Fri, Mar 22, 2019 at 7:23 AM Stefan Sperling wrote: > > INT64_C() returns a 'LL'-suffixed constant on OpenBSD, and int64_t > is indeed a 'long long': > *That's* what I've been missing, thanks! BSD is wrong. It should have been using the "fastest" shortest-int that represented 64-bits, but

Re: svn commit: r1856042 - in /apr/apr/trunk: build/apr_common.m4 configure.in include/apr.h.in

2019-03-22 Thread William A Rowe Jr
On Fri, Mar 22, 2019 at 6:58 AM wrote: > Author: ylavic > Date: Fri Mar 22 11:52:22 2019 > New Revision: 1856042 > > URL: http://svn.apache.org/viewvc?rev=1856042=rev > Log: > Use stdint types and inttypes formats when both available. > > Which should be the case on modern platforms, no change

Re: Verifying printf() formatting of types

2019-03-22 Thread Stefan Sperling
On Fri, Mar 22, 2019 at 11:55:27AM +, Yann Ylavic wrote: > On Fri, Mar 22, 2019 at 9:45 AM Yann Ylavic wrote: > > Both apr_time_t and apr_interval_time_t are (apr_)int64_t, which is > > probably format "%lld" on OpenBSD, so we'd need to determine > > APR_INT64_T (and all of our numeric _FMT)

Re: Verifying printf() formatting of types

2019-03-22 Thread Stefan Sperling
On Fri, Mar 22, 2019 at 09:45:38AM +, Yann Ylavic wrote: > Both apr_time_t and apr_interval_time_t are (apr_)int64_t, which is > probably format "%lld" on OpenBSD, so we'd need to determine > APR_INT64_T (and all of our numeric _FMT) with > APR_CHECK_TYPES_FMT_COMPATIBLE too. Yes, I agree.

Re: Verifying printf() formatting of types

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 9:45 AM Yann Ylavic wrote: > > On Fri, Mar 22, 2019 at 9:24 AM Ruediger Pluem wrote: > > > > On 03/20/2019 11:00 AM, Stefan Sperling wrote: > > > On Tue, Mar 19, 2019 at 07:30:09PM -0500, William A Rowe Jr wrote: > > >> According to my observations, apr_time_t should

Re: Verifying printf() formatting of types

2019-03-22 Thread Yann Ylavic
On Fri, Mar 22, 2019 at 9:24 AM Ruediger Pluem wrote: > > On 03/20/2019 11:00 AM, Stefan Sperling wrote: > > On Tue, Mar 19, 2019 at 07:30:09PM -0500, William A Rowe Jr wrote: > >> According to my observations, apr_time_t should match the APR_TIME_T_FMT > >> token in every case. Please inspect

Re: Verifying printf() formatting of types

2019-03-22 Thread Ruediger Pluem
On 03/20/2019 11:00 AM, Stefan Sperling wrote: > On Tue, Mar 19, 2019 at 07:30:09PM -0500, William A Rowe Jr wrote: >> According to my observations, apr_time_t should match the APR_TIME_T_FMT >> token in every case. Please inspect that line of httpd code to see how some >> non-apr_time_t value