> We avoid using variable-length arrays in our codebase. ... Hear hear, however, I wanted to avoid the "small mess" that allocate/free would cause (one or more of ++sloc, labels, if-nesting); ... > But two, they are limited in size and the failure mode is not graceful. ... ... however, my main issue is that - I don't know what's a sane allocation size. > ... The "4096" is scary here ... While scary, it is "a safe" upper high. The first time the string ends up in pathspec.c for processing it's here: entry = argv[i]; which comes from here parse_pathspec(pathspec, magic_mask, flags, prefix, parsed_file.v); and I don't know what's the maximum size of `parsed_file.v[0]` > Is this "%4096[^)]" actually valid? I don't think scanf understands > regular expressions. I was suprised too - but it's not regex. see: https://www.cplusplus.com/reference/cstdio/scanf/#parameters - 4th/3rd row from the end %s is greedy and there would be no other way to limit `sscanf` to not include `)` on its first variable. > ... though I'm not sure I understand what that is looking for ... I think it will help you see what I am trying to achieve if you read at the warning message / testcase https://lore.kernel.org/git/20210326024005.26962-2-stdedos+git@xxxxxxxxx/#iZ30t:t6132-pathspec-exclude.sh And, to clean up the testcase: git log --oneline --format=%s -- ':!(glob)**/file' I guess it should be now obvious what am I targetting: If someone naively mixes short and long pathspec magics (`!`, and `(glob)`), short form takes precedence and ignores long magic / assumes long magic as part of path. (If it's not obvious, all the more reason to include such warning)
