Re: bmake bug with expanding pattern macro replacements

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 27 Apr 2020 14:44:42 +0200
    From:        (Joerg Schilling) <schily%schily.net@localhost>
    Message-ID:  <20200427124442.ArfNW%schily%schily.net@localhost>

  | Do you believe you need a better method since the standard method only 
  | works in 100% of the cases?

What POSIX actually says is:

    If a <percent-sign> character appears as part of subst1 or subst2 after
    any macros have been recursively expanded, the results are unspecified.

This makes it hard to know just what is really supposed to happen when
there is a % char in one or the other of them.

What's the method in ancient make that has this stuff to match a literal %
character?

What happens when there is more than one % character in subst1 or subst2 ?

Is any of this stuff actually specified anywhere?


kre

ps: FYI Christos Zoulas actually fixed the problem you reported already
in NetBSD make - how long before that change filters into the bmake
distribution I don't know.   My questions above are because one of our
make tests started failing after the change.   The root cause of that
failure is (I believe) because it was assuming the previoys behaviour
where an implicit '%' was inserted after the '=' if there was no '%'
in subst2, but it happens that the test is testing removing a suffix
that contains a literal '=' and a literal '%' - hence subst1 contains
two '%' characters.    It appears as if in practice, the "match anything"
% is always the first char of subst1 (though your smake documentation
suggests it need not be) and any later '%' is simply literal?   But what
if we want a literal '%' in the prefix part?   And what happens if there
are multiple '%' chars in subst2.

Overall I think I concur that no-one, ever, should go anywhere near this
disaster of an incredibly badly designed and documented feature - it is
no wonder that POSIX says the results are unspecified.