Calvin Wan <calvinwan@xxxxxxxxxx> writes: > 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".
