The problem is those aren't available on all platforms YET, so the only safe way is to use the macros in limits.h to pick a type.

Do you mean that there is a mainstream platform that doesn't have the types, or that there is some obscure platform that very few people would encounter that doesn't have them? I think that people who fall into the latter category are fairly specific, have rather special needs, and know about them to begin with. (I wouldn't be surprised if various embedded platforms didn't have all of these types, but those are hardly common cases.)

Hmm, and even if you did find that e.g. uint16_t was unavailable on a system, you could always typedef the appropriate system type. It seems better than playing guessing games w.r.t. type sizes: use conventions whenever possible, and on those rare occasions that you can't because of a special purpose or legacy platform, work around it.

Nope sure haven't, everybody's been busy with this Littlehorn conversation. If the answer was put out there I missed it in all the confusion of people debating the difference between int and sh_int and all that. Of course by now I've forgotten the original topic of this thread and haven't gone back to read my original post yet. I'm not even going to respond to anything Littlehorn said in hopes of avoiding further derailment. Oh well, such is the way of internet forums sometimes.

Err, that "confusion" about short vs. int is exactly the answer to your problem… :wink:

Yes, you can already define uint16_t and friends, or your own guaranteed types yourself within C89 standards.
All stdint.h really does is just include a blasted new level of testing configurations, and the additional namespace
pollution that forces removal of existing code that defines uint16_t and friends.

#ifdef HAVE_STDINT_H
# include <stdint.h>
#else
# ifdef HAVE_LIMITS_H
# include <limits.h>
# else
# something testing other stuff
# blah blah.

Anyway the real problem is that after 38 years(?), integer overflow is still undefined behavior.