3.82 isn't the latest. It looks like someone beat you to it:
Differences between revisions 3f6bb04e75e5a02f23339c9d4bec99b22d430803 and
6405534814f04899890a2d932db9a4985fd772fe:
2012-02-26 21:34:51 + psm...@gnu.org
(6405534814f04899890a2d932db9a4985fd772fe)
Check for possible buffer overf
Kindly consider my fix for the lack of bounds checks in implicit.c
Index: make-3.82/implicit.c
===
--- make-3.82.orig/implicit.c
+++ make-3.82/implicit.c
@@ -488,6 +488,9 @@ pattern_search (struct file *file, int a
dir
On Fri, Jun 27, 2014 at 2:52 PM, Tom Varga wrote:
> b.zoo1 really only depends on b.bar1
> b.zoo2 really only depends on b.bar2
>
> However, only one rule (and tool) is used to build both b.bar1 and b.bar2
>
> I really don't want force b.zoo1 to artificially depend on b.bar2 as it's
> not a real
I guess this bug is pretty much what I'm dealing with.
However, it also exhibits itself even when not using pattern rules. ie :
b.foo :
touch b.foo
b.bar1 b.bar2 : b.foo
touch b.bar1
touch b.bar2
b.zoo1 : b.bar1
touch b.zoo1
b.zoo2 : b.bar2
touch b.zoo2
The
b.zoo1 really only depends on b.bar1
b.zoo2 really only depends on b.bar2
However, only one rule (and tool) is used to build both b.bar1 and b.bar2
I really don't want force b.zoo1 to artificially depend on b.bar2 as it's
not a real dependency.
I was really just hoping to be able to convince gnu
On Fri, Jun 27, 2014 at 11:24 AM, Tom Varga wrote:
>
> On page 120 of the gnumake manual, it mentions support for pattern
> rules with multiple targets.
>
> This pattern rule has two targets:
> %.tab.c %.tab.h: %.y
> bison -d $<
>
> So, if I have a simple rule that looks like:
>
> %.bar1 %.bar2 :
On page 120 of the gnumake manual, it mentions support for pattern
rules with multiple targets.
This pattern rule has two targets:
%.tab.c %.tab.h: %.y
bison -d $<
So, if I have a simple rule that looks like:
%.bar1 %.bar2 : %.foo
touch $(*F).bar1
touch $(*F).bar2
and then do:
> touch a.foo
Follow-up Comment #2, bug #42599 (project make):
Yeah, I realized later that there is an ambiguity problem. The obvious answer
is to allow the prefix char if it is preceded by exactly the same whitespace
as the rule line.
I think that's worthwhile.
___
Follow-up Comment #1, bug #42599 (project make):
FYI, .RECIPEPREFIX was added in GNU make 3.82.
I agree the error message is incorrect. In fact we shouldn't even be making
that extra check in the case where RECIPEPREFIX is set.
I'm not sure I agree with the preceding whitespace request though.
