Follow-up Comment #2, bug #35063 (project make):

According to RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt):

... octets may be encoded by a character triplet consisting of the character
"%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which
forming the hexadecimal value of the octet. (The characters "abcdef" may also
be used in hexadecimal encodings.)

Therefore I believe URL encoding aka percent encoding _requires_ all three
characters, and thus omitting a leading 0 would be disallowed by definition.

Though the unreserved set seems pretty inert wrt make, I still think this
feature should not be limited to the restricted set. Its main value IMO is
that while currently there's one trick for getting a space past the makefile
parser and another for backslashes and another for colons etc, the
percent-encoding scheme is regular and predictable. A user could easily write
a script to convert a string to its make-percent-encoded equivalent. Having to
consider each character separately to determine whether its a "may", "must",
or "must not" would bring back the pain of special casing.

Although makefiles are of course not URLs, the practice of allowing any octet
to be encoded has always been tolerated. From RFC 1738 again:

"... characters that are not required to be encoded (including alphanumerics)
may be encoded ..."

WRT when the expansion is done, I'm not well enough versed in the intricacies
to have an opinion.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35063>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-make mailing list
Bug-make@gnu....
https://lists.gnu.org/mailman/listinfo/bug-make