> On 2019/05/17, at 6:17, Matthew DeVore <[email protected]> wrote:
>
> We do have to require the combine operator (& or +) and % be encoded. For
> other operators, there are three options:
>
> ...
> 3. Require encoding of a couple of "reserved" characters that don't appear in
> filters now, and don't typically appear in UNIX path names. This would allow
> for expansion later. For instance, "~&%*+|(){}!\" plus the ASCII range [0,
> 0x20] and single and double quotes - do not allow encoding of anything else.
>
> 4. Same requirements as 3, but permit encoding of other arbitrary characters.
I tried implementing the reserved characters idea, and considering that
it was a small amount of code, I think it's worth it:
+static const char *RESERVED_NON_WS = "\"\\'[]{}!@#$^~*+";
+
+static int has_reserved_character(
+ struct strbuf *sub_spec, struct strbuf *errbuf)
+{
+ const char *c = sub_spec->buf;
+ while (*c) {
+ if (*c <= ' ' || *strchr(RESERVED_NON_WS, *c))
+ goto found_reserved;
+ c++;
+ }
+
+ return 0;
+
+found_reserved:
+ if (errbuf)
+ strbuf_addf(errbuf, "must escape char in sub-spec: %c", *c);
+ return 1;
+}
+
