Re: bmake bug with expanding pattern macro replacements

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

    Date:        Tue, 28 Apr 2020 13:46:01 +0200
    From:        (Joerg Schilling) <schily%schily.net@localhost>
    Message-ID:  <20200428114601.IBh31%schily%schily.net@localhost>

  | The feature is well designed, but gmake does not implement it correctly.

You didn't explain, and your example did not show, how one puts a
literal % in subst2 (the replacement string).   My tests using smake
didn't produce anything that worked - of course, since nothing documents
this (available to me) I'm just guessing and might not have guessed
the appropriate magic.

  | This is why the POSIX standard did call parts of it unspecified.

That's normal when different implementations are different - which is
what happens when the original implementation is not widely available
and people only encounter it from examples they see, and have to guess
what is intended to happen.

I believe Christos fixed our version to be compatible with gmake
(gmake is easily available to test against).

  | shows that gmake implements a backslash to escape the patter funtion
  | but on the other side only supports "zero of one" instead of the
  | designed "any number of %"

But no-one not using propriatary software knows about it.   The smake
man page certainly doesn't say anything about that.

It appears as if gmake also allows \ to escape a % on the RHS (in subst2)
to escape a % (smake doesn't).

However, while our doc says (and our implementation does, or did, I haven't
tested the updated version yet):

     :old_string=new_string
          This is the AT&T System V UNIX style variable substitution.  It must
          be the last modifier specified.  If old_string or new_string do not
          contain the pattern matching character % then it is assumed that
          they are anchored at the end of each word, so only suffixes or
          entire words may be replaced.  Otherwise % is the substring of
          old_string to be replaced in new_string.

          Variable expansion occurs in the normal fashion inside both
          old_string and new_string with the single exception that a backslash
          is used to prevent the expansion of a dollar sign (`$'), not a
          preceding dollar sign as is usual.

The final part looks to be the wrong way to do it, it appears as if both
gmake and smake use $$ to get a literal '$' into those strings, just the
same as would be used elsewhere in a Makefile - perhaps our implementation
was based upon an earlier buggy implementation of something?

Since I doubt that anyone in the BSD world ever uses this archaic
(and until recently, not really working) modifier form (given there
are much better alternatives) perhaps that ought to be altered, so
we're compatible with the others?

kre