From: Derrick Stolee <stolee@gmail.com>
Date: Mon, 31 Aug 2026 12:28:39 GMT
Subject: Re: [PATCH v2 1/7] banned-die: create header for banning of functions
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:

>> 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