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. Regards, Yann.
