On Tue, Mar 14, 2017 at 12:03:22PM -0400, Wayne wrote:
> On Tue, Mar 14, 2017 at 02:15:56PM +0200, Lena--- via Exim-users wrote:
> > > >> It triggers when a macro name contains the sequence /_[ODH]/.
> > > >
> > > > Does it include $header_Date: ?
> > > > A workaround: $header_date:
> > >
> > > Macro, not header.
> >
> > Even comment lines are searched for /_[ODH]/
> > As far as I undrestand, every config line is searched before parsing.
> > So, such line triggers creation of builtin macros:
> >
> > condition = ${if match{$rheader_Date:}{\N \+0[56]00\N}}
> >
>
> The additional 'if ((p == t) ...' block below corrects the initial
> problem.
>
> if (!macros_builtin_created)
> {
> const uschar * t, * p;
> uschar c;
> for (t = s; (p = CUstrchr(t, '_')); t = p+1) {
> if (c = p[1], c == 'O' || c == 'D' || c == 'H')
> {
> /* Don't trigger builtins on substrings. */
> if ((p == t) || (isspace(p[-1]) || (p[-1] == '=') )) {
> // fprintf(stderr, "%s: builtins create triggered by '%s'\n", __FUNCTION__, s);
> macros_create_builtin();
> break;
> }
> }
> }
> }
>
> Unfortunately it still triggers if an assignment that should trigger
> builtins is commented.
>
> Ex.
>
> NAME = CFG_DIR
> will NOT trigger (good)
>
> NAME = _DIR
> will trigger (good)
>
>
> # NAME = _DIR
> will trigger (bad)
>
> Is there a reason to scan within comment blocks?
>
I assume based on the lack of responses that it's not expected that
comment content be scanned at all? It certainly looks that way based
on the code. I'll look into preventing that as well.
I can supply a patch for both if it makes sense.
Am I the only one that cares about this? Seems strange that no one
else has run into it.
Wayne
