Thanks for merging my last intsafe.h patch! On Wed, Feb 25, 2026 at 12:47 AM LIU Hao <[email protected]> wrote:
> > +#define UINT32_MAX 0xffffffff > > +#define UINT_MAX 0xffffffff > > ... why no `u` here? > For all these macros, I decided to use no suffix if possible. A suffix is not needed here because in the C99 specification the type of an unsuffixed hexadecimal constant will be the first type in this list that can represent it: 1. int 2. unsigned int 3. long int 4. unsigned long int 5. long long int 6. unsigned long long int So in the systems we are targeting, 0xffffffff will be an unsigned int since it cannot be represented by an int. If you want a suffix for clarity, I can add one, but I don't think it's necessary. However, I do use ull instead of ll in macros like ULONGLONG_MAX because I don't want readers to see ll and assume the type is simply long long. If there is some version of C or C++ where this rule is different, and we care about supporting it, let me know and I'll add it to my test suite! > +#ifdef __LP64__ > > +#define LONG_MIN (-0x7fffffffffffffff - 1) > > +#define LONG_MAX 0x7fffffffffffffff > > +#define ULONG_MAX 0xffffffffffffffff > > And why no `l` here? > Since an int is only 32-bit, in 64-bit Cygwin the compiler will choose long int for LONG_MIN & LONG_MAX, and it will choose unsigned long int for ULONG_MAX. (I haven't tested 32-bit Cygwin, which is end-of-life.) > > > +#ifdef _WIN64 > > I think this should be `#if defined _WIN64 || defined _LP64`, as > Cygwin/MSYS2 never defines `_WIN64` > It worked for me because instafe.h includes wtypesbase.h, which usually includes windows.h, which includes _mingw.h, which includes mingw-w64's _cygwin.h, which has: #ifdef __x86_64__ #define _WIN64 #endif Should I include _mingw.h directly from intsafe.h to make the chain shorter? I think we have lots of places in the code where we check _WIN64 to see if we are on a 64-bit system and we'd rather not complicate all of those. > +#define PTRDIFF_T_MIN (-0x7fffffffffffffff - 1) > > +#define PTRDIFF_T_MAX 0x7fffffffffffffff > > +#define SIZE_T_MAX 0xffffffffffffffff > > Still no `u` here? > Yep. The compiler will choose an appropriate unsigned type, and my automated tests confirmed it is SIZE_T. > > +#define INT_PTR_MIN (-0x7fffffffffffffffll - 1) > > +#define INT_PTR_MAX 0x7fffffffffffffffll > > +#define UINT_PTR_MAX 0xffffffffffffffffull > > +#define LONG_PTR_MIN (-0x7fffffffffffffffll - 1) > > +#define LONG_PTR_MAX 0x7fffffffffffffffll > > +#define ULONG_PTR_MAX 0xffffffffffffffffull > > +#else > > +#define PTRDIFF_T_MIN (-0x7fffffff - 1) > > +#define PTRDIFF_T_MAX 0x7fffffff > > +#define SIZE_T_MAX 0xffffffff > > On 32-bit targets, `SIZE_T` is `unsigned long` but `size_t is `unsigned > int`, so in Microsoft headers, > they have > > - `SIZE_T_MAX` is the maximum value of `size_t` which is `0xffffffff`, > and > - `_SIZE_T_MAX` is the maximum value of `SIZE_T` which is > `0xffffffffUL`, and > - `SSIZE_T_MAX` is the maximum value of `SSIZE_T` which is `2147483647L`. > > The fact that `SIZE_T_MAX` is defined inconsistently is probably a > mistake, so they need `_SIZE_T_MAX`. Yeah, that was a special case I had to handle. My patch already defines those macros correctly. Thanks for taking a look! --David Grayson _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
