Re: [PATCH 3/6] common.h: move non-compat specific macros and functions from git-compat-util.h
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 16, 2023, 22:30 UTC
- Message-ID
- <xmqqwn17sydw.fsf@gitster.g>
- In-Reply-To
- <20230516170932.1358685-4-calvinwan@google.com>
Calvin Wan <calvinwan@google.com> writes:
Show 5 quoted lines
> git-compat-util.h has grown to a large and difficult to read file partly > because its set of functionality is overloaded. Besides being a > compatibility file that ensures Git's operation across different > operating systems, it has also become a dumping ground for commonly used > macros and static inline functions.
Yeah, compat-util.h started out as a (surprise) "compatibility aid" that isolates the knowledge of platform specific inclusion order, what feature macros to define before including which system header file, etc. "A dumping ground for common stuff"---aptly put ;-).
> This commit separates out macros and static inline functions that are > compatible across operating systems into common.h.
It sounds a bit too generic a name to me, but OK.
At some level I am more or less indifferent, in the sense that both compat-util and common need to be included by a .c file anyway, whether it is _our_ source, or in a future third-party source that wants to link with the libified part of Git, so it does notreally make much of a difference if ARRAY_SIZE() is defined in which one of these two headers. But presumably such a future third-party source may arrange their own system support using their own counterpart to compat-util without using ours, and if that is what motivates this change, I could understand why a more-or-less git-agnostic common.h could be a good idea.
Everything, other than sane-ctype macros, does look like a generally useful git-agnostic helper functions. If we were to move in this direction, I probably would prefer to separate sane-ctype macros in a separate header, simply because they are _designed_ to override system supplied ones and some third-party source may not want to use such a "feature".