From: Kyle Lippincott Date: Tue, 27 Feb 2024 00:56:28 GMT Subject: Re: [PATCH v5 1/3] pager: include stdint.h because uintmax_t is used Message-ID: In-Reply-To: On Mon, Feb 26, 2024 at 4:20 PM Junio C Hamano wrote: > > Kyle Lippincott writes: > > > The condition added 13 years ago was, IMHO, backwards from what it > > should have been. The intent is to have stdint.h included. We should > > include stdint.h. I suspect that 17 years is enough time for that > > platform to start conforming to what is now a 25 year old standard, > > and I don't know how we can verify that and have this stop being a > > haunted graveyard without just trying it and seeing if the build bots > > or maintainers identify it as a continuing issue. > > The nightmare of Solaris might be luckily behind us, but the world > does not only run Linux and GNU libc, and it is not just > vs . This is about general code hygiene. > > > If it's still an > > issue (and only if), we should reintroduce a conditional, but invert > > it: if there's no stdint.h, THEN include inttypes.h. > > But it would give the wrong order in general in the modern world, > where is supposed to include and extends it. > > We use inttypes.h by default because the C standard already talks > about it, and fall back to stdint.h when the platform lacks it. But > what I suspect is that nobody compiles with NO_INTTYPES_H and we > would unknowingly (but not "unintentionally") start using the > extended types that are only available in but not in > sometime in the future. It might already have happened, It has. We use PRIuMAX, which is from inttypes.h. I think it's only "accidentally" working if anyone uses NO_INTTYPES_H. I changed my stance halfway through this investigation in my previous email, I apologize for not going back and editing it to make it clear at the beginning that I'd done so. My current stance is that should be either (a) including only inttypes.h (since it includes stdint.h), or (b) including both inttypes.h and stdint.h (in either order), just to demonstrate that we can. > but I do not know. I haven't compiled with NO_INTTYPES_H for some > time (to experiment), and I haven't met a platform that actually > requires NO_INTTYPES_H defined to build. Once after such a change > is made without anybody being knowingly breaking some rare platform, > if nobody complains, we can just drop the support to allow us to > limit ourselves to , but since we hear nobody complaining, > we should be OK with the current rule of including system header > files that is embodied in header file. > > In any case, your sources should not include a standard library > header directly yourself, period. Instead let > take care of the details of how we need to obtain what we need out > of the system on various platforms. I disagree with this statement. We _can't_ use a magic compatibility header file in the library interfaces, for the reasons I outlined further below in my previous message. For those headers, the ones that might be included by code that's not under the Git project's control, they need to be self-contained, minimal, and maximally compatible. > > Thanks.