You may be right that it’s the best solution. It’s horrible to contemplate, but it might be so.

The best solution is to say that uid_t et al are probably no larger than uint64_t, and introducing a static_assert that makes sure that the compiler will fail if it's not.

Sure, someone might come up with an architecture where that's not true. But even in an intmax_t-is-really-the-largest-integer-type world [which hasn't been true for the major C compilers for the past decade or so!], I can almost assuredly come up with some compilation modes that still conform with whichever C version you use that still causes your code to fail horribly. I don't think there's any architecture where uid_t et al would exceed uint64_t, and until such an architecture comes to exist, it's quite frankly not worth caring about.

Oh I agree, it's bad.

> "To the first problem you can use a classic mod 10 divide by 10 loop to convert into a string digit by digit."

But the "physical" size of the number as represented in memory can change across platforms, no?