ilyakurdyukov 64-bit compilation concerns

[nothings]

Originally posted by @ilyakurdyukov in https://github.com/nothings/stb/issues/1610#issuecomment-2300776853:

This is insane. Whitelisting 64-bit architectures in 2024 should be considered a serious crime against portability. In times when most architectures are 64-bit. How many years have compilers had predefined macros like these?

#define _LP64 1
#define __LP64__ 1
#define __INTPTR_WIDTH__ 64

And this whitelisting nonsense only for the uintptr, which has been available in stdint.h since C99, for 25 years!

And yet, people who can't find their architecture on the list ask to add it. They don't ask to fix this trashfire once and for all.

I wanted to create a bug about this, but judging by the number of open and unanswered issues and PRs, it looks like this project is closer to abandonware than to anything else.

[nothings]

@ilyakurdyukov

stb libraries support pre-C99 compilers. it would certainly be possible to only test for the pre-C99 compilers, handle those cases, and rely on stdint.h for everything else, but it's not clear off the bat which compilers would break if you did that, so relying on _LP64, __LP64__, or __INTPTRWIDTH_\ would be better, but of course that requires knowing if there are 64-bit platforms that don't define any of those and handling those cases, so it's probably still going to be a bit whack-a-mole, and the changeover is just going to break a ton of compilers, so this falls in that category of 'sucks, but more work to fix than is likely to be saved'. Possibly new libraries should do this though, but there are unlikely to be many of those as there are already too many.

To your general comments:

There are lots of unmerged PRs because releases are only done infrequently, on the order of once or twice a year.

There are plenty of open issues because they generally need more discussion or because they represent real issues that need to be addressed somehow. They are typically not "unanswered" (though some issues may slip through the cracks and be in that state; if so, they should be re-awoken from their slumber).

This is free software and we generally try to do our best to make it useful to people, but it may not be useful to everyone, for example people using compilers not supported by the "whitelist". That's not the end of the world if it's still useful to some people.

This software is supported through unpaid labor from, in part, burnt-out programmers who already barely have any energy to spend on fixing bugs. If we reply to unhelpful comments that just sucks up more of the energy and means it will be that much longer until the next release. So, y'know, maybe don't be a dick about it.

[ilyakurdyukov]

I thought I was conservative because I reject C++ and C99 is enough for me. But there are people who reject even C99.

but of course that requires knowing if there are 64-bit platforms that don't define any of those and handling those cases

Not platforms, but some legacy compilers, meanwhile new 64-bit architectures are created every few years. But legacy compilers will not appear anymore.

This whitelist is also incorrect because for 64-bit architectures there are modes with 32-bit pointers, for example -mx32 for x86_64. In this mode, compilers set the macros __ILP32__ and _ILP32.

[ilyakurdyukov]

Compiler developers have given people many ways to write portable software. Even if you want to maintain compatibility with pre-C99 compilers, the availability of C99 can be detected by another macro. For example:

#ifndef stbsp__uintptr
#if __STDC_VERSION__ >= 199901L
#include <stdint.h>
#define stbsp__uintptr uintptr_t
#elif defined(__UINTPTR_TYPE__)
#define stbsp__uintptr __UINTPTR_TYPE__
#elif (defined(_M_X64) /* list of macros for legacy compilers here */ || defined(__LP64__) || defined(_LP64) || __INTPTR_WIDTH__ == 64) && !(defined(__ILP32__) || defined(_ILP32) || __INTPTR_WIDTH__ == 32)
#define stbsp__uintptr stbsp__uint64
#else
#define stbsp__uintptr stbsp__uint32
#endif
#endif