httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: pre-patch: struct sockaddr_in error messages
Date Sat, 25 Oct 1997 01:10:27 GMT

On Sat, 25 Oct 1997, Martin Kraemer wrote:

> On Fri, Oct 24, 1997 at 04:08:56PM -0700, Dean Gaudet wrote:
> > I disagree with making this another flag to aplog_error for the exact same
> > reasons that I don't like aplog_error in the first place -- it assumes it
> > knows far more about what you're doing than you do.  What happens when I
> > want to print two addresses in an error message?  Say I want to print the
> > proxy local and remote addresses?  Or say I want to print
> > r->connection->local_addr?  What, add another 3 flags? 
> What I was thinking of was not inventing another flag for aplog_error().
> In fact, I think the APLOG_NOERRNO solution is suboptimal.
> Instead, i would have preferred if aplog_error()'s format scanner had been
> extended so that when the caller had said

aplog_error()'s format scanner lives in a file called util_snprintf.
That's the scanner I changed...

>     aplog_error(APLOG_MARK, APLOG_ERR, r->server,
> 	"Cannot read file %s: Error %E", filename, errno);
> and got
> [Fri Oct 24 01:07:12 1997] [error] Cannot read file /bla: Error (2)No such file or directory
> in place of today's
>     aplog_error(APLOG_MARK, APLOG_ERR, r->server,
> 	"Cannot read file %s", filename);
> [Fri Oct 24 01:07:12 1997] [error] (2)No such file or directory: Cannot read file /bla
> One would simply pass the format string containing fields like %E for the
> "(errno)strerror(errno)" string, %S for the IPaddr:port string, %H for
> the HTTP return code, and other useful strings to aplog_errno(). The
> advantage, as Dean said already, is that these fields can be given
> multiply in one call, and are expanded on the fly, without overwriting
> each other.
> Similar to Dean's proposals, it could then have looked like this:
>     aplog_error(APLOG_MARK, APLOG_ERR, r->server,
> 	"Returning %H: Client %A gave invalid password to server %A:%P",
> 	    client->sin_addr.s_addr,
> 	    server->sin_addr.s_addr, port);

Yup, these are a logical continuation of what I was proposing. 

Oh, BTW, %S can't be used because it's the posix way of specifying a
wchar_t *, which is why gcc was complaining to me. 

glibc allows the user to replace the semantics of any %letter, or to
extend the set of %letters.

And another btw... talking about code bloat.  Notice http_bprintf.c and
util_snprintf.c.  bloat.  The mere existence of http_bprintf.c indicates
that we understand the POSIX *printfs are very limiting.  Ben's sure to
pipe up at some point and point out that C++ Streams solve this in a nice
way :)  (They do, 'cept I hate the syntax.)

We can replace both of these, and skirt the ap_snprintf debate, with a
single core routine:

    int vformatter(int (*write_func)(void *data, const void *buf, size_t len),
		    void *data, const char *format_string, va_list ap);

Which will naturally have a wrapper:

    int formatter(int (*write_func)(void *data, const void *buf, size_t len),
		    void *data, const char *format_string, ...);

And then it can have wrappers for whatever other types of things we
normally want to format into -- like BUFF *, constant length buffers,
and dynamically allocated buffers.

POSIX doesn't give you anything like this, yet this is what we really
need.  So we can't use what the operating system supplies.


View raw message