mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#215517 22/09/09 02:48 PM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
Am I insane or does this code not provide the correct/expected answer?

Code:
//echo -a $!and(4294967296,4294967295) == $and(4294967296,4294967295)


I'm pretty sure the answer should be 0, as in the testcase below:
Quote:
<n00p> relipmoc: int main(void) { printf("%u\n", 4294967296 & 4294967295); return 0; }
<relipmoc> n00p > 0

s00p #215534 22/09/09 05:57 PM
Joined: Jun 2007
Posts: 933
5
Hoopy frood
Offline
Hoopy frood
5
Joined: Jun 2007
Posts: 933
mIRC handles a max of 32 bits in this operation.

11111111111111111111111111111111 = 4294967295

Any decimal value above that becomes a 33-bit binary value.

5618 #215539 22/09/09 06:34 PM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
Don't you think I already worked that out? Wait, you did read my post, right?

The mIRC help file states "$and(A,B) Returns A binary and B.", which isn't true. That is my point. >32-bit ops work for other functions, such as $base, so why not this one?

heh, but then again, what would $not(0) return?

s00p #215542 22/09/09 08:53 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It seems you already know the answer.

The help file is not incorrect, it's just incomplete, but that's not a new accusation as the help file is rarely that detailed. $and() *does* return binary AND of A and B, it just does it with a 32-bit operation. That part is simply undocumented (because mIRC is not a language that needs to concern itself with bits and bytes).

The expected result should take into account this 32-bit limitation.

Maybe at some point mIRC will support 64-bit numbers, you can suggest this, but there are other ways to handle that.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #215543 22/09/09 09:18 PM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
I'm curious as to how you would go about defining the mIRC scripting language without bits and bytes. I suppose you could call the wildchars "magic", and the tokens, well lets just say a random butcher decides where tokens begin and end wink

The help file is incorrect until it documents the behaviour. $and(4294967296,1) is not the correct value for binary 4294967296 and 1. synonymously, 4294967296 binary and 1 is 0, not 1. Even if mIRC wrapped 4294967296 into a 32-bit int, the behaviour isn't consistent. If you wrap 4294967296 into a uint32_t, you get 0. $and(0,1) = 0. not 1.

// 32-bit operations...
<n00p> relipmoc: uint32_t x = atoi("4294967296"); printf("%u\n", x);
<relipmoc> n00p > 0
<n00p> relipmoc: uint32_t x = atoi("4294967296"); printf("%u\n", x & 1);
<relipmoc> n00p > 0

s00p #215545 22/09/09 10:53 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
"The help file is incorrect until it documents the behaviour."

Again, no. The help file may lack details, but the statement "Returns A binary AND B" is not incorrect on its own. It doesn't state that this will work for any number, and it would be just as incorrect to assume that it would, especially within the context of mIRC (a language where you should already know of and expect many size/functional limitations). And funny enough, mIRC doesn't even say A and B should be numbers, or even that they should be base 10. Hey, maybe we should complain that mIRC doesn't accept $and(0A, 0A) as valid input. I mean, under MY assumptions that should work, therefore the helpfile is wrong-- right?

But this is all pointless semantics and completely besides the point. The help file is not a spec for behaviour, it's merely a pointer. It's not meant to enumerate every detail, although that would be nice. If you can't deal with this and still want to call the help file "incorrect", go ahead, but I don't see what that changes.

As far as the "wrapping" is concerned, you're making implementation assumptions. Who says mIRC integer overflow is involved here? How do you know its not truncation? Again, the behaviour is defined by.. the behaviour. That's how it works. If you want, you can think of the help file as saying: "takes the binary AND of A and B. If A or B are greater or equal to 2^32 the result is undefined."-- Happy now?

If you're not, make a feature suggestion to extend the behaviour to 64-bit integers on the Feature Suggestion forum. Complaining about it here is completely unproductive.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #215547 23/09/09 02:12 AM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
Don't assume that I'm making an assumption. Each bit in the result should be set if and only if each of the corresponding bits in the converted operands is set. Sign bits are included in this internal representation. This is irrelevant to the fact that a value outside of the range produces unexpected results.

Code:
alias bin {
  var %x = 1, %s = $null
  while (%x < $1) {
    %s = $+($iif($and($1,%x),1,0),%s)
    %x = %x * 2
  }
  return %s
}
//echo $bin(4294967295) == $bin(4294967296) == $bin(4294967297) == ...

s00p #215550 23/09/09 04:30 AM
Joined: Aug 2006
Posts: 183
T
Vogon poet
Offline
Vogon poet
T
Joined: Aug 2006
Posts: 183
"Because Mirc only works with 32 bits."

"NO, THAT'S WRONG."

"Really, it doesn't work in 64 bits."

"NO, THAT'S WRONG."

...

Don't feed the trolls.


Yar
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I believe you missed the issue entirely.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
s00p #215553 23/09/09 05:36 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
Don't assume that I'm making an assumption.
Seriously? Forgive me, I almost died laughing of the sheer recursive idiocy of that statement.

Is it still an assumption if I use your own words?

Quote:
If you wrap 4294967296 into a uint32_t, you get 0. $and(0,1) = 0. not 1.


So, if 4294967296 is "wrapped" (read: integer overflow) into a uint32_t data type... that is not an assumption? Telling us what function mIRC is using is not an assumption? Telling us what data structure mIRC uses is not an asumption? Cause you know, there's zero chance your assumption is wrong and mIRC is obviously not simply using, say, the value 1 in this case, or maybe the value 2147483647 which is incidentally what atoi("4294967296"), atoi("4294967297"), etc. give on 32bit systems (unlike your examples, this is what I got). But you don't make assumptions.

When's your birthday... I'll buy you a dictionary.

But you're right. This is all irrelevant to the fact that mIRC doesn't support the integer range above 2^32. I'm glad you worded it so succinctly.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #215585 25/09/09 03:34 AM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
... and yet you make more assumptions:
Quote:
or maybe the value 2147483647 which is incidentally what atoi("4294967296"), atoi("4294967297"), etc. give on 32bit systems


This is technically undefined behaviour. That is, the behaviour is left to be defined by the implementation of C, not the standard. I also consider it stupid that you're arguing with me, rather than attempting to see my point of view. If you wanted to post some code that was beneficial to this topic, rather than arguing pointlessly, your code might look like this.

To the power who be, please lock this topic so that no more childish, useless comments can be posted.

s00p #215591 25/09/09 05:20 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
This is technically undefined behaviour.


Great, you acknowledge the concept of undefined behaviour. The same concept applies to $and (since it likely depends on that very function).

Case closed.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #215619 26/09/09 04:52 AM
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
"I'm right. It's undefined, and that's the way it is" - this is the message I get from you. Well, it might not be that way in the future, if a compiler that Khaled chooses to use defines the behaviour of atoi() differently. Why not make an effort to use a function that defines the behaviour, or better yet takes advantage of C/C++'s silent wrapping to produce a correct behaviour, providing one of the two arguments isn't truncated? Well, if you want to be an idiot... then feel free to argue against a change that would eliminate undefined changes for $and/$or/$xor...

Last edited by s00p; 26/09/09 04:53 AM.
s00p #215622 26/09/09 05:25 AM
Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
This is like watching a tennis match - and I am getting a crick in the neck.

Undefined behaviour means undefined results.

If you truncated the extra bits - the original problem you complained about would still exist (an unexpected answer to a function). If you wrapped the extra bits - the original problem you complained about would still exist. You can't both truncate and wrap.

Nor can you magic extra bits out of a routine if it doesn't handle it!

if you want to suggest
Quote:
... it might not be that way in the future ...
then it becomes just that ... a suggestion. Until then, you have to accept that things are the way they are. Perhaps, instead of complaining about something that isn't going to change in the next few weeks, you could scrpt a way around it - do your own checking?

Cheers,

DK



Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
Sure, you can truncate and wrap. That's exactly what truncating does!

No, you can't add extra bits magically, but you can perform a binary 'and' operation and get correct results providing ONE of the inputs is within the range (that is, isn't wrapped, or truncated). The other one may be. Wouldn't it be better to define the behaviour this way, than using an undefined function and (at the moment) providing an incorrect answer if one of the inputs is out of range?

"The C Programming Language" by Kerninghan and Ritchie is a good book to read before you go saying stupid things, Darwin_Koala.

s00p #215627 26/09/09 04:24 PM
Joined: Oct 2005
Posts: 1,741
G
Hoopy frood
Offline
Hoopy frood
G
Joined: Oct 2005
Posts: 1,741
It seems to me that these functions that can only handle 32-bit numbers should only ACCEPT 32-bit numbers. Any input that is outside the numeric range accepted by $and/$or/etc should be considered invalid input. If you input a number greater than 0b11111111111111111111111111111111 you should get a standard mIRC error message or a $null/0 return from the function. In my opinion, these examples should give the same result.

$and(bonnie,clyde) = $null
$and(9999999999,9999999999) = $null

The functions currently return 0 for invalid input (non-numbers), but since 0 can be a valid result ($and(1,0) = 0), I think that they should be changed to return $null instead. This would cause the functions to always give a known result (valid result or $null).

A simple pseudocode:

Code:

function and {
  if either input is not a number return NULL
  elseif either input is too big or too small return NULL
  else return inputA (BINARY_AND) inputB
}



-genius_at_work

Last edited by genius_at_work; 26/09/09 04:26 PM.
s00p #215634 26/09/09 08:41 PM
Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
Oops, obviously I haven't read my own copy of "The C Programming Language" often enough, nor my own copy of Deitel's C++ Programming guide, nor my copies of the MC68000 design books. That is not to mention the other books in my library that deal with computer design.

What argv0 was originally telling you, and that you refuse to listen to, is that the behaviour of the function is undefined for inputs greater than 32-bit.

Genius_at_work notes that mIRC handles this undefined behaviour in a consistent manner.

Your point that it would be useful to have the behaviour of the function defined differently for invalid input is understood by all here. However, because this is a design feature - it is a Suggestion, rather than a bug. Sometimes a fine line?

Perhaps you should learn how computers work and note the inputs of others before you accuse anyone of saying "stupid things".

Cheers,

DK


Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
What I'm telling you, and argv0, is that this is all irrelevant. My point is that some effort should be made to define the behaviour, because mIRC does on occasions work with larger numbers. If you weren't stupid, you wouldn't be arguing against consistency in behaviour for the future. Whenever someone asks for a feature and you argue "no, that would break scripts", I'm likely to point out that a revision of $and/$or/$xor is required to prevent scripts from breaking in the future. That is my point, leave it at that. No more replies, please.

edit: thankyou, genius_at_work.

Last edited by s00p; 27/09/09 05:16 AM.
s00p #215642 27/09/09 05:38 AM
Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
Originally Posted By: s00p
... If you weren't stupid ...


There is no need to be rude. Your ignorance has already been demonstrated - in that you think "truncating" and "wrapping" are the same thing (read your previous posts).

If you also bothered to read my post - you see that I made no argument whatsoever about breaking any scripts.

If you read genius_at_work's post - you would see that the behaviour at the moment is consistent. You should also note that I agree that a better form of behaviour would be preferred. Feel free to make a suggestion on how this can be achieved.

Please try an understand that computers are not magical beings and they have limitations. In this case, the discussion was around a limitation of 32 bits. If you try to push the computer past this limitation using functions that are only designed to work with 32 bits then the functionality will break. If you want to work with large numbers, then use functionality that is optimised to work with large numbers. less chance of something breaking or meeting undefined behaviour.

I hope I have made this point clear. Your point (suggesting an improved feature to mIRC) is also clear to me. If you had made this point in the first place instead of leading yourself up the garden path you may not have had to resort to belittling others who have tried to help and educate you.

As further reading, somewhere in the archives here (over the last couple of years) there have been other discussions in replacing outputs of functions with "$null" to get around similar poorly defined outputs.

Cheers,
DK.



Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
s00p #215643 27/09/09 06:29 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
My point is that some effort should be made to define the behaviour


Your original point seemed to revolve around expected behaviour, not documentation, but anyway...

I believe this thread is a testament to the effort made to sufficiently define the behaviour for you. Has it not been sufficiently defined?

If you meant the help file, you're barking up the wrong tree. Adjustments to the help file are rarely made. You can feel free to suggest it, but it's not likely to happen.

One of the great things about mIRC's community is that there is a relatively active forum and at least a few IRC support channels whose purpose is to act as an addendum to the help file. The help file will never be perfect or cover every detail of the language, so, in cases like these, a forum or IRC channel is a much better source of information. There is also a wiki that has some interesting information.

With that in mind, why is a response on the forums not a sufficient description of the behaviour?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
Since when did I say that truncating and wrapping are the same thing? OK, perhaps this thread could do with a summary before it dies:

1. I stated that $and evaluated to an incorrect value when either input A or input B are too high.
2. 5618 agreed.
3. argv0 disagreed, stating that the mIRC help file isn't incorrect, but incomplete.
4. I disagreed with argv0, stating that the mIRC help file is incorrect until it documents the behaviour. I provided an example which involved a function that isn't relevant and shouldn't have been brought into the discussion (stupid me!).
5. argv0 disagreed with me. In a strange twist, argv0 then agreed with me, stating that the mIRC help fle is incorrect and requires further elaboration. argv0 then assumed that I was making implementation assumptions.
6. I disagreed with argv0's assumptions, attempting to bring the discussion back into relevance by stating the definition of a "binary and" operation.
7. Thrull made a rather humorous attempt at pointing out the whole love/hate relationship.
8. argv0 informs Thrull that he missed the point.
9. argv0 disagreed with me again. He then brought irrelevance in the form of assumptions that would have been fair to state, if they were stated. He then made an assumption regarding atoi returning the same value "on 32bit systems", and at the same time technically agreed with me regarding this undefined behaviour.
10. I state that a helpful participant would be better off acknowledging my point of view and discussing possible alternatives that may be better defined and provide better results. I give one example of such alternative, that would return an infinitely greater variety of correct result.
11. argv0 agrees in regards to the undefined behaviour.
12. I agree in regards to the undefined behaviour.
13. Darwin_Koala agrees in regards to the undefined behaviour. Darwin_Koala then states "If you truncated the extra bits - the original problem you complained about would still exist (an unexpected answer to a function)" (only true if both inputs are truncated) and "You can't both truncate and wrap." He then suggests that it isn't important because it's not going to break anything in the near future, thus disagreeing with my definition of a helpful participant.
14. I disagree with Darwin_Koala's statement: "You can't both truncate and wrap." I state that truncating results in wrapping (for the record, this is not a statement of equality). I would like to state, from the ISO C99 standard: "C's unsigned integer types are 'modulo' in the LIA&#8722;1 sense in that overflows or out-of-bounds results silently wrap." What exactly does that mean? Well, if you take a number that is larger than an unsigned integer (eg. that 'overflows' the unsigned integer), it silently wraps. For example, if a 64-bit unsigned integer is assigned to a 32-bit unsigned integer, the 32-bit unsigned integer's result is wrapped, and truncated, at the same time.
15. genius_at_work stated "functions that can only handle 32-bit numbers should only ACCEPT 32-bit numbers." genius_at_work provides another possible, and perfectly acceptable alternative.
16. Darwin_Koala attempts to defend his ego by listing part of his library. Darwin_Koala then agrees that the behaviour is undefined. Darwin_Koala attempts to agree with something that genius_at_work didn't state: "Genius_at_work notes that mIRC handles this undefined behaviour in a consistent manner." He then states that I should learn how computers work before telling him he's stupid.
17. I state my point again, that the behaviour should be defined rather than left undefined, to prevent scripts from breaking.
18. Darwin_Koala states that I stated that "truncating and wrapping are the same thing". Darwin_Koala stated that genius_at_work agrees that the behaviour is consistent.

Read my post again. Just because going up results in coming back down doesn't mean they're the same thing. Now tell me, where did I state that truncating and wrapping are the same? You may not have made any argument against my point, but it is still my point, and you are still bringing irrelevancy to this thread.

Read genius_at_work's post again. Now tell me, where within genius_at_work's post, would I "see that the behaviour at the moment is consistent." I forgive you if English is your second language, but please learn to read more accurately. Also, please refrain from bringing irrelevancy to this thread.

Thankyou, s00p.

edit: argv0, I missed your most recent post. I apologise. My original point could be about either. The documentation can not define the behaviour, unless a defined behaviour is used. If a defined behaviour is used, then it should be noted in the help file. At the moment, I suspect that it's entirely up to the compiler.

Last edited by s00p; 27/09/09 08:50 AM.
s00p #215647 27/09/09 08:57 PM
Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
In the interest of reason, and ensuring that the general readership are properly informed:

genius_at_work noted that
Quote:
... The functions currently return 0 for invalid input (non-numbers), ...

Thus, mIRC treats this consistently. It might be (in our opinion) consistently bad - but it is still consistent.



However, you appear to have a different view and want to put other views down with a cry of "irrelevance", so please answer me this:
- What do you get from the C Manual (your reference, not my chosen one) that sheds light on this discussion, and how does it help solve the issue.
- Truncating and wrapping are not the same, 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.
- Rather than dismissing the points out of hand - try to explain why they are irrelevant. From my point of view - the points made are exteremely relevant and it is you who is missing the point. Again, I am listening.

Try to learn where Australia is, and then revise your assumption on whether English is, or is not, my first language.

Try not to assume that people are stupid, either - it is rude, unnecesary. From your tone and language I too can make assumptions - and I assume that I have been working in IT longer than you have been on this planet.

Taking into account genius_at_work's point - the behaviour is defined for invalid inputs. Perhaps not defined the way we would like it. The help file may not be too clear on this either.

Cheers,

DK





Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
Joined: Aug 2006
Posts: 183
T
Vogon poet
Offline
Vogon poet
T
Joined: Aug 2006
Posts: 183
Seriously? You guys are still responding to this? I know tolls in this forum are rare, but c'mon, this is exactly what's happening.

You've given him the answer, he refuses to believe you and insults you. The sooner you stop responding, the sooner this thread can get buried.


Yar
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
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&#8722;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:
Quote:
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.

Last edited by s00p; 28/09/09 06:57 AM.
Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
.. I was hoping to at least correct some of the misinformation so that the real readers of this thread could learn. However, the last response rambled even more incoherently than previous ones.

In a battle of wits, I have been bested by an unarmed man. I now retire, hurt.

Cheers,

DK.


Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
Joined: Jul 2008
Posts: 236
S
s00p Offline OP
Fjord artisan
OP Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
lol @ me == troll. I've asked for no more responses on a number of occasions, and I'm not giving in to those trolls to see nothing done about this so wink if I'm a troll then I'm a troll

Page 1 of 2 1 2

Link Copied to Clipboard