Update of bug #65273 (group make):
Status:None => Wont Fix
Open/Closed:Open => Closed
___
Follow-up Comment #10:
I have decided, for now
Follow-up Comment #9, bug #65273 (group make):
Note that the trick in John's book no longer works without warnings in the
current Git-based code:
$ ./make
Makefile:3: warning: invalid variable name ' '
Makefile:4: warning: invalid variable reference ' '
Makefile:4: [ ]
make: *** No targets. Sto
Follow-up Comment #8, bug#65273 (group make):
[comment #3 comment #3:]
> The problem is that (a) there is no way to create a variable name
containing, or consisting of, whitespace
Sure there is:
Makefile:
```
SPACE :=
SPACE := $(SPACE) $(SPACE)
$(SPACE) := $(SPACE)
$(warning [$( )])
```
Output:
Follow-up Comment #7, bug#65273 (group make):
[comment #6 comment #6:]
> Leaving these checks disabled by default is not a good solution since the
very people who need this help most, will not benefit from them.
I agree. It took me a while to understand some of the GNU Make extensions a
few years
Follow-up Comment #6, bug#65273 (group make):
I mean, there IS a reasonable way to get the same effect; I showed one
possibility in my response. Yes, it looks slightly different but the result
is the same and there are no warnings. Alternatively the Emacs makefiles
could disable these new warnin
Follow-up Comment #5, bug#65273 (group make):
FWIW, I think it is very unfortunate that GNU Make started warning about this
trick, especially if there is no reasonable way of getting the same effect by
other means.
___
Reply to this item
Follow-up Comment #4, bug#65273 (group make):
[comment #3 comment #3:]
> It's usually a good idea to check the NEWS file for things that might cause
differences in behavior
Thanks. I'll do that next time first. :)
I grep'd for the error message and found it through git blame so it didn't
take too
just a single space without comment seems to me to be allowing an
extremely common potential error to be silently accepted.
I wonder how common this particular little trick is, out in the world. Of
course it could easily be changed to do something like:
. :=
$(info $. foo)
Follow-up Comment #2, bug#65273 (group make):
Finally got around to looking into this. From what I can tell it was an
intentional change from commit 03ecd94488b85adc38746ec3e7c2a297a522598e. The
previous commit doesn't warn and one referenced onward can be controlled with
--warn=(ignore|warn|error
Follow-up Comment #1, bug#65273 (group make):
I was able to reproduce this on a FreeBSD VM. The GNU Make in ports is version
4.3 and does not output the warnings. When using gmake from master they are
outputted. On a separate note, FreeBSD fails when building in maintainer mode
due to a #warning p
URL:
<https://savannah.gnu.org/bugs/?65273>
Summary: Potential bug in the info function?
Group: make
Submitter: collinfunk
Submitted: Thu 08 Feb 2024 02:01:44 AM UTC
Severity: 3 - Normal
Item
On Sat, 2022-05-21 at 14:34 -0400, Dmitry Goncharov wrote:
> On Sat, May 21, 2022 at 12:25 PM Paul Smith wrote:
> > Maybe what you're saying is that make should throw an error or
> > warning if you try to add an order-only prerequisite to a phony
> > target, telling you that it will have no effect
On Sat, May 21, 2022 at 12:25 PM Paul Smith wrote:
> Maybe what you're saying is that make should throw an error or warning
> if you try to add an order-only prerequisite to a phony target, telling
> you that it will have no effect on your makefile?
Having a phony target depend (usually indirectl
Hi Paul and Jacob,
On 5/21/22 18:24, Paul Smith wrote:
On Wed, 2022-05-18 at 14:36 -0700, Jacob Kopczynski wrote:
The thing that the docs refer to as "impose order" is not a single
thing, but two. I would characterize a normal prerequisite as doing
three things rather than two:
- update-marking
On Sat, 2022-05-21 at 19:06 +0200, Alejandro Colomar wrote:
> By "once all children are complete" you are implying the "existence"
> of the children (which make(1) doesn't really check, but one can
> think of it as if it did).
Perhaps that's the confusion. Make doesn't care about files at all per
On Wed, 2022-05-18 at 14:36 -0700, Jacob Kopczynski wrote:
> The thing that the docs refer to as "impose order" is not a single
> thing, but two. I would characterize a normal prerequisite as doing
> three things rather than two:
> - update-marking: cause a target to be marked out of date if the
>
On Wed, May 18, 2022 at 5:37 PM Jacob Kopczynski
wrote:
>> - it might make sense to state explicitly that order-only prereqs
>> which are phony behave in all ways like standard prerequisites.
This statement is simply incorrect.
Order-only prerequisites which are phony do not behave like reg
The thing that the docs refer to as "impose order" is not a single thing,
but two. I would characterize a normal prerequisite as doing three things
rather than two:
- *update-marking: *cause a target to be marked out of date if the prereq
is marked out of date
- *require-existence: *require the pre
On Wed, 2022-05-18 at 10:22 -0700, Jacob Kopczynski wrote:
> I believe I understand. The name "order-only" is highly misleading
> and should be changed - it does considerably more than "only"
> "order"; the only thing it does not do is check the timestamp.
As described in the docs there are only t
I believe I understand. The name "order-only" is highly misleading and
should be changed - it does considerably more than "only" "order"; the only
thing it does not do is check the timestamp. This portion of the
documentation *particularly* needs changing:
> Occasionally, however, you have a situat
On Tue, 2022-05-17 at 22:32 +, Martin Dorey wrote:
> > all your targets are .PHONY, and thus are always rebuilt anyway
>
> If you "make down", the rule for "down-clean" doesn't run. They're
> only rebuilt if something causes them to be considered.
>
> > order-only prerequisites are totally
ay, May 17, 2022 14:20
To: Jacob Kopczynski ; bug-make@gnu.org
Subject: Re: Potential Bug: `.PHONY` targets and order-only prerequisites
* EXTERNAL EMAIL *
On Tue, 2022-05-17 at 14:00 -0700, Jacob Kopczynski wrote:
> I'm unsure whether this is a bug or just undocumented, but I
On Tue, 2022-05-17 at 17:20 -0400, Paul Smith wrote:
> this says two things: first, that b and c will both be rebuilt (if
> necessary) before a's recipe is started,
I guess I should be more clear about the "(if necessary)". What I mean
is the same as if you had run "make b" or "make c" and make h
On Tue, 2022-05-17 at 14:00 -0700, Jacob Kopczynski wrote:
> I'm unsure whether this is a bug or just undocumented, but I found a
> confusing interaction in a simple Makefile:
You are misreading the documentation. I will quote:
> A normal prerequisite makes two statements: first, it imposes an
>
I'm unsure whether this is a bug or just undocumented, but I found a
confusing interaction in a simple Makefile:
> .PHONY: up
> up: down | down-clean
> docker-compose up -d
> .PHONY: up-clean
> up-clean: down-clean up
> .PHONY: down
> down:
> docker-compose down
> .PHONY: down-clean
> down
On Wed, 12 Jun 2019 16:02:15 -0400, Paul Smith wrote:
> I get that having a make that "does everying right out of the box" is
> seductive, but I'm not on board at this point.
I actually don't care about whether or not it's "in the box" of make.
I care about making it easy to perform the check.
If
On Tue, 2019-06-11 at 22:09 -0400, David A. Wheeler wrote:
> Basically, when running a rule, make could enable strace to see
> what is *actually* getting checked/read & written, compare that to
> what the rule *claims* are the prerequisites & targets, and then
> complain about differences.
At this
On Wed, 12 Jun 2019 19:22:09 +0100, Tim Murphy wrote:
> If you use strace to detect dependencies you might have to do a thorough
> patent search. I will say no more because it's not my place to.
The odds of an *enforceable* patent on strace seem extremely remote from
the information I could find.
rform incremental builds (because all the necessary rules are not
> > written, or are written incorrectly), it's also a way to trivially
> > make a build that is mysteriously broken because one or more files
> > will not be properly rebuilt.
>
> Of course, that'
s also a way to trivially
> > make a build that is mysteriously broken because one or more files
> > will not be properly rebuilt.
>
> Of course, that's a potential problem for *any* use of make.
> Garbage in, garbage out. I use automated dependency generation
> where
ritten, or are written incorrectly), it's also a way to trivially
> make a build that is mysteriously broken because one or more files
> will not be properly rebuilt.
Of course, that's a potential problem for *any* use of make.
Garbage in, garbage out. I use automated dependency g
Update of bug #49116 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
URL:
<http://savannah.gnu.org/bugs/?49116>
Summary: w32/subproc/sub_proc.c: Fixed potential null pointer
dereference.
Project: make
Submitted by: jotik
Submitted on: Sat 17 Sep 2016 04:50:18 PM GMT
Severity: 3 -
On Tue, May 7, 2013 at 10:24 PM, Zhenbo Xu wrote:
> 2. Out of bound
> file: function.c
> function: func_sort
> At line 1150: words = xmalloc (wordi * sizeof (char *));
> The value of wordi may be 1.
>
> At line 1171: if (i == wordi - 1 || strlen (words[i + 1]) != len
> words[i + 1] may cause overf
Hi,
I'm a developer of a static analysis tool canalyze.
Recently I applied it to make-3.82.
It seems some reports are real after by manually checking:
1. Null Dereference
file: hash.c
function: hash_rehash
At line 262: ht->ht_vec = (void **) CALLOC (struct token *, ht->ht_size);
Should we check ht-
I scanned make 3.82 with my static analysis tool, and found 3 potential
bugs. The bugs are described in attached XML files, each describing the
trigger path. I reviewed the bugs myself. From the code alone, each is
possible. But I am not sure if it could happen in practice.
Would you please take
I attached another bug reports for review.
于 04/01/2012 01:19 PM, Xu Zhongxing 写道:
> I scanned make 3.82 with my static analysis tool, and found 3 potential
> bugs. The bugs are described in attached XML files, each describing the
> trigger path. I reviewed the bugs myself. From the c
Hello,
I ran across perhaps a bug or need for another feature at least. If a list
of items has words beginning with both upper and lower case letters, the
resulting $(sort $(LIST)) will result in all capital letter words coming
before the lower case words. In this case, Zebra.c would appear before
Update of bug #21824 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
Update of bug #21823 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
Follow-up Comment #3, bug #21823 (project make):
This is confusing, and the lack of detailed comments in hash.c doesn't help.
However, I think this particular bug is impossible. Looking at the
implementation of hash_find_slot(), it seems there is no way for that function
to return null. So, th
Follow-up Comment #2, bug #21823 (project make):
You are right. I just thought it was worth reporting the error because the
test for NULL indicates something is "fishy." BTW,
imho I would assume all the statements in a program serve a
purpose, specially those that cannot be caught by the compi
Follow-up Comment #1, bug #21823 (project make):
Just because there is a check for NULL does not necessarily mean that a NULL
value can ever happen, "potentially". Unless you assume that all statements in
a program serve a particular purpose.
___
URL:
<http://savannah.gnu.org/bugs/?21824>
Summary: Another potential NULL ptr dereference, on remake.c
Project: make
Submitted by: marciobuss
Submitted on: Tuesday 12/18/2007 at 03:33
Severity: 3 -
URL:
<http://savannah.gnu.org/bugs/?21823>
Summary: Potential NULL pointer dereference on hash.c,
hash_insert
Project: make
Submitted by: marciobuss
Submitted on: Tuesday 12/18/2007 at 03:18
Severity: 3 -
I audited GNU make 3.80 for potential buffer overruns due to sprintf
calls, and came up with the following patch. Most of the buffer
overruns are fairly theoretical: they can occur only on hosts where
integers are fairly wide. Some of them are more practical, though:
they can occur on hosts that
46 matches
Mail list logo
