Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001505 [Issue 8 drafts] Shell and Utilities Comment Omission 2021-08-10 10:14 2021-08-11 10:55
Reporter quinq View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 2
Name Quentin Rameau
User Reference
Page Number 2935
Line Number 98369
Final Accepted Text
Summary 0001505: Make doesn't seem to specify unset macro expansion behaviour
Description Hello,

I was looking for an actual specification of
what happens when trying to expand an undefined macro.

Intuition would be that it expands to an empty string,
but this doesn't seem to be specified at all,
or maybe I missed that somewhere else.

Could an implementation be allowed
to generate an error on such case (or other behaviour)
without having this defined?
Desired Action Specify that trying to expand an unset macro
results in an empty string.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2021-08-10 11:23

I agree the standard doesn't say what happens if make tries to expand an unset macro.

However, I'm not sure adding a requirement that it expands to an empty string would be useful. This is because applications cannot rely on any macro being unset just because they have not set it. Under "Default Rules" the standard says "Implementations may provide additional macros and rules." So any macro name the application tries to use without setting might happen to be the name of a macro the implementation provides, and thus could expand to something unexpected.

It would be better to state that the behaviour is unspecified and warn that applications should explicitly set macros to an empty string if they want them to expand to an empty string.
joerg (reporter)
2021-08-10 12:43

We already have:

If the original value of the variable named by string1 is an empty string, the final result shall be an empty string.

in the current draft of Issue 8.
geoffclare (manager)
2021-08-10 13:30

Re: Note: 0005433 That's an addition related to pattern macro expansions. See [^]

And it has a mistake: "variable" should be "macro"!

We should fix that as part of the resolution of this bug.
joerg (reporter)
2021-08-10 13:44

There is another mistake: it says "word", where np ns with no % in between is ment.
kre (reporter)
2021-08-10 14:28

Re Note: 0005432

   I'm not sure adding a requirement that it expands to an empty string
   would be useful.

From the perspective you're looking at it, you're right, applications
should not depend upon a macro being undefined, and hence necessarily
an empty string when expanded, but that's not the only issue.

   It would be better to state that the behaviour is unspecified

That would be unfortunate, as, as one possible implementation, that could
lead to a situation where an implementation expanded undefined macros as
the name of the macro, rather than as an empty string (or an error).

Then when an application expects a macro to be defined (eg: CC) and does

     $(CC) file.c

in some rule, and the implementation instead of doing the expected invocation
of the C compiler, instead invokes the CC command (which might be anything
at all), that would have potential for very bad things (TM) to happen.

So, I think the standard needs to define how undefined macros are treated
when encountered - either as an error, or an empty string (and I think that
the empty string version is what is actually done in practice, so that one
should win), rather than simply say "unspecified". There can be an
APPLICATION USAGE note telling makefile writers not to depend upon a macro
being undefined, if anyone really believes this is a real problem - I mean,
why could anyone write
   whatever ${FOO} and more
expectig FOO to be undefined, and so to generate
   whatever and more
when they could have just written that in the first place? So I think
this issue most probably isn't real (ie; no-one expects macros to be
undefined) but one often expects them to be defined in situations where
they might in fact not be.
quinq (reporter)
2021-08-11 10:55

Re: 0005432

That is a good point indeed about implementations being authorized to provide additional macros.

The solution of specifying that this is unspecified, and adding a warning note sounds good to me.

Re: 0005436

While I like the idea of having a defined behaviour, the bottom line is “don't do it” so it doesn't really matter there. As you said, it seems that most implementations (?) expand to an empty string, but $(MYTOOL) file could still expand to MYTOOL if an implementation decided to provide that specific macro anyway.

As for the use cases of having empty macros, for example that could happen on variable file inclusions where some macros are defined, or not.
Other cases could happen too, but in the end yes, correct solution is to explicitely set them if they are to be used.

- Issue History
Date Modified Username Field Change
2021-08-10 10:14 quinq New Issue
2021-08-10 10:14 quinq Name => Quentin Rameau
2021-08-10 10:14 quinq Section => EXTENDED DESCRIPTION
2021-08-10 10:14 quinq Page Number => 2935
2021-08-10 10:14 quinq Line Number => 98369
2021-08-10 10:46 geoffclare Project 2008-TC2 => Issue 8 drafts
2021-08-10 11:23 geoffclare Note Added: 0005432
2021-08-10 12:43 joerg Note Added: 0005433
2021-08-10 13:30 geoffclare Note Added: 0005434
2021-08-10 13:44 joerg Note Added: 0005435
2021-08-10 14:28 kre Note Added: 0005436
2021-08-11 10:55 quinq Note Added: 0005437

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker