> Yeah, until the compiler figures out it's really not a size_t and that it's free to do whatever it likes to your operation. That's not true. Being gracious,

> Yeah, until the compiler figures out it's really not a size_t and that it's free to do whatever it likes to your operation. That's not true. Being gracious, parent was saying that if you treat another scalar type as a size_t (or vice versa) something sane happens. The standard guarantees that size_t is an unsigned integer type. If you use any other scalar type where a size_t is expected, it will be converted to a size_t correctly, even if it has less precision than a size_t. If you use a size_t where a less precise scalar type is expected, the behavior is perfectly defined as long as the value stored by the size_t can be stored in the less precise type. The result is implementation defined, or an implementation defined signal is raised, if it cannot be represented in the less precise type. Either way, the compiler is never free to do whatever it likes in this case. In most cases, doing this is perfectly safe. Compilers are free to warn (and they do!) users when this happens. For instance, GCC and Clang both will warn on this behavior if you supply `-Wconversion`. But you never will see totally unreasonable code generated by compilers when this happens.