You seem to suffer from a condition that limits you to selective reading. The fact that the functions return 0 for "invalid input (non-numbers)" is not even the slightest bit relevant to the fact that it's not providing correct output for numbers that are out of range. Again, please
learn to read accurately. This is irrelevant because the input we're dealing with is numerical. Stating that this quote, with ellipsis at each end, implies consistency just goes to show how easy it is to omit key aspects of the paragraph and derive pure bullshit from it. Allow me to take the same quote, omitting the rest of the paragraph and derive some more bullshit to counter your own: $and(0,0) returns 0, thus 0 must be a non-number. That would be consistent, correct?
1. "What do you get from the C Manual (your reference, not my chosen one) that sheds light on this discussion, ..."?
Consistency, which is not the equivelant of some pseudo-realism derived from an quote that unreliably displays obvious signs of omissions. If you can't find the answer, assume it to be implementation defined. In this case, I can't find the answer within the mIRC help files. It's not fair enough to say that mIRC is a single implementation (because this can, will and already has changed many times), so I'm kicking up a stink.
2. "... and how does it help solve the issue."
It provides examples of this consistency. I've already quoted them, but for the benefit of a moron: "C's unsigned integer types are 'modulo' in the LIA−1 sense in that overflows or out-of-bounds results silently wrap." This quote defines a perfectly acceptable solution to the problem: wrapping. Truncating is irrelevant, as I have already said so many times before, and wasn't brought into this conversation by me.
3. "Truncating and wrapping are not the same, ..."
correct.
4. "... and truncating does not result in wrapping. Please provide some examples to demonstrate your perspective. I am listening and waiting to learn from the obvious master."
uint32_t x = 0, *y = &x, z = y; // <--- this may result in truncation of the pointer to uint32_t y.
I never did imply that truncating and wrapping are the same. That was another case of your selective reading. Real number truncating is irrelevant to this thread, because we're dealing with numbers that are outside of the range, not numbers that have decimal points. This is an example of the form of truncating we've been referring to, straight from the draft:
EXAMPLE 2 In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the 'integer promotions' require that the abstract machine promote the value of each variable to int size
and then add the two ints and truncate the sum. Provided the addition of two chars can be done without
overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
produce the same result, possibly omitting the promotions.
Please stop bringing irrelevance into this thread.
I know where Australia is; I live there. It would be an assumption if I were to say that everyone who lives in Australia speaks English as their first language. It would be most rude, too.
If you have been working in IT longer than I have been on this planet, then perhaps it's time for your retirement. Your wisdom is deteriorating, and the inebidable signs of brain damage are starting to show. Immediate attention may be required if you believe you can accurately pinpoint "tone" within posts on a forum.
You may find what mIRC considers to be "valid" and "invalid" inputs, are not necessarily what atoi() considers to be valid/invalid. In this case if atoi() is being used (quite likely), then it considers a number greater than UINT_MAX or smaller than -UINT_MAX to be invalid, and as a result the return value is saturated (consists of all 1's in it's binary representation). The result is inconsistency between the return value that atoi() provides (assuming atoi() is being used) and the return value that $and provides for invalid input.
