One of Carl's comments in R3-Alpha complained about the lack of a standardization of integer sizes in C:
"One of the biggest flaws in the C language was not to indicate bitranges of integers. So, we do that here. You cannot 'abstractly remove' the range of a number. It is a critical part of its definition."
So he did some empirical platform detection to define things like REBI32 for a signed 32-bit integer, REBU64 for an unsigned 64-bit integer, etc.
But once C99 arrived, the file <stdint.h> offered several basic types, and basically covered the needs with types that had names like int32_t and uint64_t:
Fixed width integer types (since C99) - cppreference.com
So Ren-C was changed to use the C99 names and include <stdint.h>. For pre-C99 compilers, it used a portable shim called "pstdint", which it maintained its own copy of in the repository:
By similar reasoning, booleans were shimmed with another found-file:
Ren-C Has Embraced C99, So Why Keep These Shims?
C99 is now a prerequisite for building the system.
It may be that some pre-C99 standards compiler could still build Ren-C with these shims, though it would need variadic macro support. The odds of a compiler having that support yet lacking things like bool and int32_t are fairly slim.
In any case, these esoteric compilation environments could be "shimmed" by hacking in versions of stdint.h and stdbool.h to their include directories. I feel like that's the responsibility of the build environment at this point... and that the Ren-C codebase need not be carrying the baggage.
So I'm pulling the files out. If anyone is on an esoteric platform and trying to build but finds these definitions being missing is the only problem, then they should dig up pstdint and pstdbool.