Hi,
While adding some debug log statements to a module I'm working on, I ran
into the problem that ap_log_error (in apache 2.2) does not support %zd
or %zu conversion for type_t arguments. This was problematic to make the
code compile on both 32 and 64 bit platforms. So I made a small wrapper
(see below) to workaround the problem. I suggest to build support for
%zd and %zu conversion into the unified logger.
/**
* ap_log_error does not support %zd or %zu conversion for type_t arguments
* So with ap_log_error one would have to specify either %d or %ld,
depending on the
* platform (32-bit or 64-bit). This violates the whole purpose of
type_t, which
* was introduced in C exactly to provide cross-platform compatibility...
* This wrapper function supports %zd and %zu conversion parameters.
* Note that it truncates the logged message to 1000 bytes, so don't use
it to log messages that might
* be longer
*/
void ap_log_error_wrapper(const char *file, int line, int level,
apr_status_t status, const server_rec *s,
const char *fmt, ...)
{
char msg[1000];
va_list ap;
va_start(ap, fmt);
vsnprintf(msg, sizeof(msg), fmt, ap);
ap_log_error(file, line, level, status, s, "%s", msg);
}
Cheers,
Alex
Op 27-07-10 23:11, Stefan Fritsch schreef:
> On Wednesday 21 July 2010, William A. Rowe Jr. wrote:
>
>> On 7/21/2010 4:35 PM, Stefan Fritsch wrote:
>>
>>> And I agree that a unified logging formatter would be nice, but
>>> this is not something that will be done before 2.3.7 and it
>>> would likely mean an incompatible API change for modules
>>> providing handlers for mod_log_config. IMHO, this can wait until
>>> 3.0.
>>>
>> IMHO, it must not. The simple reason is that the more code
>> duplication we introduce, the more opportunity for flaws and
>> maintenance headaches during the 2.4 lifecycle. I'd accept
>> waiting for this entire custom error log feature for 3.0, but
>> really would rather introduce it sooner and not later.
>>
> I fear a unified logging formatter may either delay 2.4 or not make it
> into 2.4. In 2.4, we really need some way to omit some of the fields
> we currently have in the error log prefix (> 100 chars of prefix is
> insane). But as I had less time in the last few days than I hoped, it
> does not look like my (non-unified) errorlog formatter would be ready
> for 2.3.7 in any case. So we will have time until 2.3.8 to decide what
> to do.
>
>
>> If there is a resulting API change, I think everyone is willing to
>> accept this during the 2.3-alpha/beta cycle. 2.4.0 is our
>> 'lockdown'.
>>
>> I'm willing to help with this code, although I'm just starting to
>> dig out of the hole from my two recent hand surgeries. 6-finger
>> typing isn't all that efficient :)
>>
> I think there are more important things that could use your and my
> attention than avoiding this bit of code duplication.
>
>
> Buf if you want to start a bit of technical discussion: The main
> technical difference between error and access log is that for the
> access log, everything is allocated from the request pool and then
> written to the log file (i.e. there is no length limit). For the error
> log, there is a fixed 8K buffer (allocated on the stack). For the
> error log, it is not possible to use any of the existing pools to
> avoid unbounded memory usage. The unified log formatter would either
> have to use a pre-allocated buffer or a temp pool.
>
> For my work on the error log formatter, I have stayed with the pre-
> allocated buffer. Would this be a reasonable solution for the unified
> logger? It would mean a fixed limit for the access logs lines (though
> the access log could use a larger buffer than the error log, I guess
> 16 or 32K would be enough even for the access log). The pool approach
> would require a per-thread temp logging pool (using
> apr_threadkey_private_create or the like) or creating and destroying a
> sub-pool for every log line.
>
> Which solution looks better to you?
>
>
> Cheers,
> Stefan
>
>
