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: '}'
>
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:
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
>
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
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)
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
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,
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
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
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)
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.
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
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
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
14 matches
Mail list logo