Re: [PATCH v2 1/7] banned-die: create header for banning of functions
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Aug 31, 2026, 12:28 UTC
- Message-ID
- <202e5eac-becb-4b75-80ca-5d56caf36f3a@gmail.com>
- In-Reply-To
- <xmqqh5kikkgi.fsf@gitster.g>
On 8/25/2026 4:34 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 14 quoted lines
>> It would be reasonable to name this file trace2/tr2_banned.h to be >> specific to the trace2 API, but it seems like such a restriction would >> be valuable to put in some other areas of the code, so adding it at the >> root of the tree seems like a good long-term approach. > > In other words, the functions banned by including this file are not > listed because they are banned from being used in trace2 API, but > because they may lead to die(). There may be some other traits that > we might want to avoid in certain subset of our code, and we may > have similar banned-frotz.h header to prevent direct or indirect use > of frotz. Which makes sense to me. > > Would the same approach work for the_hash_algo and the_repository, I > wonder?
I'd be curious if it would satisfy two directions for those cases:
1. Help declare a subsystem is free of these globals and thus is ready for multi-hash or multi-repo handling.
2. Help declare a subsystem is _not_ free of these globals and thus should not be _reintroduced_ into a subsystem that was declared clean.
We'd need both, in general. And we'd need to continue expanding the banned-*.h files. I am curious as to whether there are static tools that could assist with this.
Thanks, -Stolee