httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] improving line number reporting for config file syntax errors
Date Mon, 29 May 2000 22:37:20 GMT
On Mon, 29 May 2000, Jeff Trawick wrote:
> > From:
> > Date: Mon, 29 May 2000 14:37:01 -0700 (PDT)

[ meta: Jeff: maybe you can trim the headers when you quote? :-) ]

> > I like this patch because it is relatively clean with regard to how much
> > it changes things.  The basic idea to this patch, is that we pass around
> > the configfile_t variable that we use when reporting the error.  At the
> > time that we actually receive an error while reading the config file, we
> > just replace the line number in the configfile_t with the line number that
> > caused the error.
> > 
> > Ryan
> The basic idea of my patch is that we pass back a ptr to the
> ap_directive_t where we noticed the problem.

I think this is the right approach. We want access to the bad directive,
not just the line number (as Ryan's patch does).

> I don't know what we'd
> ever need besides file+line number, but it is convenient as-is and may
> be useful in the future.

Theoretically, I don't think the ap_directive_t would contain file/line
number fields. They would have a "configure source" -specific context. For
file-based configure sources this would be file/line.

> I like your patch for the brevity, but I get bad vibes from the way
> the info is passed back.  Right now, I get bad vibes from my patch
> because of the amount of changes required (albeit simple changes) but
> I like the way the information is passed back.

Third approach (synthesis of the two approaches): pass back the offending
directive via "cmd_parms". Specifically, add a new field: err_directive.

> Note also that the externalized routine ap_limit_section() has an
> additional parameter.  Comments state that it is externalized for
> mod_perl.

They can deal. I would be interested in understanding why it is
externalized, though.


Greg Stein,

View raw message