[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
func_filter_filterout ... redundant code or bug ?
From: |
Markus Mauhart |
Subject: |
func_filter_filterout ... redundant code or bug ? |
Date: |
Tue, 22 Jun 2004 15:32:03 +0200 |
Hi,
in function.c we have ...
static char *
func_filter_filterout (char *xo, char **xargv, const char *xfuncname)
... implementing the builtin functions "filter" and "filter-out",
xfuncname contains that name. xargv[0,1] are non-zero according to
code, and xargv[0] contains the pattern string.
During parsing of xargv[0], that string is written to on two occasions:
1) 1st each word inside the string is zero-terminated.
2) To handle non-literal patterns (e.g. "pfx%sfx"), function find_percent()
is used on each word and will compact the word when it contains a '%'
with one or more leading '\', by removing some of the '\' and
adding \0 at its new end.
Now func_filter_filterout() takes care to undo exactly (1)'s changes,
but it does not do so for (2)'s potential changes.
I see 3 explanations for the current semi-preservation af xargv[0]:
a) the code and data for undoing (1)'s changes is redundant, cause
xargv[0] need not be preserved (neither its value nor its strlen).
b) missing code for undoing (2)'s changes is a bug.
... IMHO not cause this bug would happen frequently enough.
c) in make's source, every caller of func_filter_filterout() knows
that "simple" patterns are preserved, while "complicated" patterns
containing "...\%..." are not value-preserved nor strlen-preserved.
... IMHO not very likely.
So may we remove the data (a_pattern::save_c) and code to undo (1)'s changes ?
Otherwise, why not remove a_pattern::save_c and replace former read-access to
it with "int save_c = pp->next ? ' ' : '\0'".
Regards,
Markus.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- func_filter_filterout ... redundant code or bug ?,
Markus Mauhart <=