On Fri, Mar 22, 2019 at 9:45 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Fri, Mar 22, 2019 at 9:24 AM Ruediger Pluem <rpl...@apache.org> 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 that line of httpd code to see how > > >> some > > >> non-apr_time_t value was passed in APR_TIME_T_FMT formatting. > > > > > > Indeed, this value is not a time_t, it's an apr_int64_t, i.e. long. > > > > > > The problematic format string is in this bit code from proxy_util.c > > > starting at line 3176: > > > > > > ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(00959) > > > "ap_proxy_connect_backend disabling worker for (%s) > > > for %" > > > APR_TIME_T_FMT "s", > > > worker->s->hostname_ex, > > > apr_time_sec(worker->s->retry)); > > > > > > This assumes apr_time_sec returns apr_time_t, but in fact apr_time_sec is > > > a macro. So the expression returns the type of the variable passed in, > > > which in this case is apr_interval_time_t. > > > > Possibly stupid idea, but what if the macro does a cast to apr_time_t? > > Would that solve the issue? > > 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.
So what about r1856042? Stefan, works for you (this is trunk only for now)?
