On Mon, Oct 21, 2024 at 08:44:01AM +0200, Patrick Steinhardt wrote:

quoted

Will it take us another 20 years to resolve all of the portability
issues which Clar suffers from (but git-compat-util.h doesn't)?
Probably not 20 years, but I don't think that it's on the complete other
end of the spectrum, either.

My assumption is that we'll iron out the issues in this release. Our
"git-compat-util.h" has grown _huge_, but that's mostly because it needs
to support a ton of different things. The Git codebase is orders of
magnitude bigger than the clar, so it is totally expected that it also
exercises way more edge cases in C. Conversely, I expect that the compat
headers in clar need to only be a fraction of what we have.

I don't really understand where the claim comes from that this is such a
huge pain. Sure, there's been a bit of back and forth now. But all of
the reports I received were easy to fix, and I've fixed them upstream in
a matter of days.

I'd really like us to take a step back here and take things a bit more
relaxed. If we see that this continues to be a major pain to maintain
then yes, I agree, we should likely rope in our own compat headers. But
from my point of view there isn't really indication that this is going
to be the case.

I'm OK with that direction. Just to be clear, I think you've done a
great job (as you always do) of responding to the issue promptly and
keeping things moving forward. And you're right that there is a good
chance that we iron out this wrinkle and never worry about it again. If
that doesn't turn out to be the case, we can iterate from there.

My thinking / response was mostly just: git-compat-util.h has many
subtle fixes we've accumulated through battle-testing. To the point that
I don't think we even know which ones are important and which are not
anymore. That's why our guidelines say that everything should include it
first, rather than trying to handle system headers themselves. Clar
violates that rule, and if it were original code within Git it probably
would have been flagged in review as such. But since it's imported,
there's some tension there between making the code as Git-like as
possible, and keeping it easy to track upstream.

I tend to err on the "fork and make it Git-like" side of that line, but
certainly there is an argument for the other way. Anyway, let's deal
with this wchar.h issue and then see if it ever even comes up again.

-Peff