ZheNing Hu [off-list ref] writes:
quoted
These global variables are problematic. The places that check them
are quite isolated, and it makes me wonder why we cannot pass a
format instance through the callchain down to get_object().
If we pass such two options In such a deep call chain, it seems not
worth to do it.
OK. After all, ref-filter.c has too many existing global variables
(starting from the used_atom[] array) that makes it impossible to be
a proper API that can be used to handle more than one invocations at
once, so two more globals aren't making it any more hopeless than it
currently is. If we wanted to make the API reentrant, we'd need a
bigger change anyway.
Or just use "static" prefix?
Yes, that is needed regardless to pass "make sparse".
TShanks.
Junio C Hamano [off-list ref] 于2021年7月2日周五 下午11:27写道：
ZheNing Hu [off-list ref] writes:
quoted
quoted
These global variables are problematic. The places that check them
are quite isolated, and it makes me wonder why we cannot pass a
format instance through the callchain down to get_object().
If we pass such two options In such a deep call chain, it seems not
worth to do it.
OK. After all, ref-filter.c has too many existing global variables
(starting from the used_atom[] array) that makes it impossible to be
a proper API that can be used to handle more than one invocations at
once, so two more globals aren't making it any more hopeless than it
currently is. If we wanted to make the API reentrant, we'd need a
bigger change anyway.
Yes, Using global variables may make the code non-reentrant.
Now I think because the "rest" is already in struct ref_array_item,
we can emulate "rest", adding these two flags "use_textconv"
and "use_filter" to struct ref_array_item. Then we can use them
in get_object().
quoted
Or just use "static" prefix?
Yes, that is needed regardless to pass "make sparse".
TShanks.
Thanks.
--
ZheNIng Hu