Hi Junio, On Mon, 12 Oct 2020, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Hi Michał, > > > > On Mon, 12 Oct 2020, Michał Kępień wrote: > > > >> @@ -5203,6 +5207,22 @@ static int diff_opt_patience(const struct option *opt, > >> return 0; > >> } > >> > >> +static int diff_opt_ignore_regex(const struct option *opt, > >> + const char *arg, int unset) > >> +{ > >> + struct diff_options *options = opt->value; > >> + regex_t *regex; > >> + > >> + BUG_ON_OPT_NEG(unset); > >> + regex = xcalloc(1, sizeof(*regex)); > >> + if (regcomp(regex, arg, REG_EXTENDED | REG_NEWLINE)) > >> + die("invalid regex: %s", arg); > >> + ALLOC_GROW(options->ignore_regex, options->ignore_regex_nr + 1, > >> + options->ignore_regex_alloc); > >> + options->ignore_regex[options->ignore_regex_nr++] = regex; > > > > A slightly more elegant way would be to have `ignore_regex` have the type > > `regex_t *` and use `ALLOC_GROW_BY()` (which zeroes the newly-added > > elements automagically). > > It may be "elegant", but we we know if it is "correct" on > everybody's implementation of regex_t? > > A struct like > > struct foo { > char *str; > char in_place_buffer[10]; > }; > > where str points at in_place_buffer[] only when it needs to point at > a very short string, and points at an allocated memory on heap, can > not be safely copied and used, and an array of such a struct breaks > when ALLOC_GROW_BY() needs to call realloc(). Keeping an array of > pointers to regex_t and growing it would not break even for such a > structure type. > > Since we cannot rely on the implementation detail of regex_t on a > single platform, I'd rather not to see anybody suggest such an > "elegant" approach. True, such an implementation detail is totally conceivable. Thanks for the sanity check. Having said that, my suggestion to use `ALLOC_GROW_BY()` was triggered by the use of `xcalloc()`, and now that I think further about it, an `xmalloc()` should be plenty enough: `regcomp()` does not need that struct to be initialized to all zero. Ciao, Dscho