hash collisions

[Rebel]

Here's an interesting quote from Ed circa 2019 (last year): "90% of coding is debugging, the other 10% is writing bugs." Hardly sounds like writing bug-free code.

It's hard to imagine you miss the humor of my signature.

As far as writing bug-free code of any size, "you are a legend in your own mind." NOBODY else agrees with you. And haven't since the late 60's...

Plenty bug-free downloadable software on the internet IMO.

[chrisw]

You seem to miss the point. Resistance to fraud should be one of the key specifications of any system for dealing with money. It is a well-known fact that criminals do exist, no matter how much we might dislike that. Failing to care about fraud resistance is neglicence.

There are societies in which actions that encourage crime are a punishable offense themselves. I think one can be fined here for leaving one's car unlocked, because that encourages theft. (I am not sure if that still applies; I never had a car.) That doesn't make ransacking unlocked cars legal here.

And yeah, criminals can be clever. So we'd better make sure we are clever in protecting ourselves from them. Making it easy for them, just because they are not supposed to do what they do would be really stupid. So yes, the book publisher is at fault. You could argue that it is his own money he is putting up for grabs (like you would be putting your own unlocked car on offer...), so that it is OK for him to do this. But of course the money lost this way doesn't really come out of the pocket of the person that designed this system. It is the one that set this up that is guilty of criminal neglicience w.r.t. the publisher (be it his client or employer).

Well, you’re about as knowledgeable about economics and business as Bob. Namely a couple of laymen,
The punch card as he described it was an invoice/receipt, sent with the book by the book company. Invoices have positive numbers on them. Their opposite is an invoice with a negative number, otherwise known as a credit note.
Bob’s friend, who he described as a clever programmer, and performing something funny and boasting about it, forged a credit note by changing the sign. Is no different to reprinting an invoice with negative numbers and then presenting it for credit payment. Or forging a bank note, or a US treasury bill, all these things are legal Fiscal instruments, convertible to cash. Credit notes happen all the time and are not unreasonably assumed good, just as US treasuries are legal currency and assumed good at the point of presentation anywhere in the world. It isn’t the task of software or bought ledger clerks to reject invoices/credit notes, nor US dollars nor US treasuries. Fraud/forgeries, unless glaringly obvious, get discovered later when the double entry ledgers don’t match up at the end of the accounting period. Then a forensic search would reveal the fraud.
Bob describing the fraud as clever, and accusing the company of bugged software is just dumb. All it reveals, apart from the ethical fail, is Bob’s lack of knowledge of accounts. Which in turn suggests his story of writing bank software, all of it, can be brought into question. We’ll let you off, since you didn’t claim to write bank software.

Your argument about criminal negligence is framed by dislike of banks presumably? A parallel case would be of an old lady who left her purse on show, gets robbed by a criminal, who then spends her money and blames her for being stupid. Or criminally negligent as you would call it.
Funny how your argumentation positions are taken for entirely social reasons, when your claim is to just use straight logic. I don’t think so.

[Rebel]

As far as I am concerned the discussion is about the possibility of bug-free software. From recent previous posts:

Me:

2. Unless I misunderstand, you pretend it's impossible to write 100% bug free code. I think you are wrong.

You:

2) You are correct, except that (a) I don't pretend, I know ...

As such it doesn't make sense to list examples of inferior software, bugs are part of programming, to assume (or in your words to know) not all can't fixed is a lack of imagination or underestimation of the capabilities of others. As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release. (Y)our experiences as lone individuals are not a good measuring rod.

Not sure how to proceed.

start:

Me neither.

You think it's impossible 100% bug free software exists, how odd.

You said "banks don't tolerate errors" or something to that effect. So I gave some counter-examples where really BIG banks had been bitten by really serious bugs.

So what?

They fix it.

What's so hard to understand?

I've already given quotes showing that the consensus is that you can't test away all bugs.

Don't call cherry picked quotes consensus, you, me and the rest of us have wriiten bug-free code playing legal moves. Or do you think Crafty in theory can play an illegal move?

Do you think, make_move and undo_move are bug-free? Or could Crafty in theory crash?

BUT, just to come back around full circle, "debugged chess program." NOW you say "As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release. (Y)our experiences as lone individuals are not a good measuring rod." So which is it? Chess programs have bugs? Or they don't have bugs. Can't possibly be both. I claim they do. You just explained why they do. So why the argument???

Proof we are talking about different things.

goto start;

Let's get this right. Not just I think that bug-free code doesn't exist. A GREAT MANY computer scientists agree. In fact I can't think of a single person that has not agreed with this. It came to a head when "A software crisis" was published. If you google "software crisis" you will discover that this was first recognized as a problem and discussed publicly somewhere around 1968. We talked about this in my undergraduate curriculum, although at the time there were no specific proposed solutions. Same holds true today. There are software design tools (Rational Rose from IBM is one, Texas Instruments developed a very good one although I don't remember what it was called - but not today's "SimpleLink" system). All of these kinds of tools do pretty well in mitigating software failures. There's been a lot of discussion on "runnable specifications" but the same problem still exists... and error in the specs produces an error in the emitted source code.

So exactly how are thousands of computer scientists "odd"? Just because Chris and you say so and say you can develop bug-free code. Wish I were that good, and I AM pretty good at writing code...

You simply have no clue about what the expression "bug free code" actually means. It does not mean software after all known bugs are fixed" just so you know. And it didn't include all previous versions of a software system, prior to the current, because in your words "they found the bugs and fixed them."

Assuming they found ALL the bugs. Why didn't they find them all in the first version released? Or the second? Or the third. But somehow, magically the last version was perfect. Until another bug shows up and they fix it. Bug-free code has no bugs of any kind. We can't even prove that is the case for ANY sizable software program (say > 5,000 lines of code to be generous. More like 500 lines of code.)

So how about coming back to reality. You can't call something bug-free if it is continually being updated to eliminate bugs. Actually that is the definition of lousy software.

I hope you will excuse me not responding on all your Gish gallop stuff, hoping for your consideration

[Rebel]

How can this be? Ed writes bug-free code?

I hope not in fact I stopped working on playing strength in 2016 after the realization that during the years a bug slipped in that made the result of matches unreliable. For example, a cutechess match of 10,000 games could give 51.8% with a LOS of 100% while running it again it could produce a negative < 50% score. That's insanity.

I recently fixed the bug, now I only have to redo approximate 7-8 years of promising candidate engine changes

Happy now?

[chrisw]

Personally, I have NEVER released a piece of code with known bugs. Or with even suspected bugs (testing simply continued to try to track them down.) That being said I have certainly released things with unknown bugs.

The most painful to me was in the 1970's. I had written about 100,000 lines of assembly language for the Xerox Sigma 9. Deep in the operating system. Main goad was to move ALL of the character-oriented hardware stuff out of the operating system and out into an attached computer to offload all the interrupt handling (each character types produced two interrupts, one for when the character was received in the Sigma 9 and one for when it was echoed back to the user. I had tested and tested this code, night after night, 10pm to 8am. For several months. We decided to "go live" on the campus computer on a Monday to test in a real user environment before handing it over to Telefile (which had taken over the xerox computer product line.

Damn thing was booted at 8am, and by 8:15 am it had crashed. A couple more attempts, a couple more crashes, couple more HUGE core dumps and off I went to test. Problem was simple. We had 64 serial lines on the I/O processor. We had only 32 on the original sigma 9 hardware. Nobody notice when we generated the operating system (anyone remember the term sysgen or system generation from the early IBM days?) my helper had left the number of serial connections at 32, which dictated the size of lots of data structures. Meanwhile, back at the ranch, the code for the front-end processor was set to 64 serial lines. When the 33rd user logged in, big problem as things started to get overwritten as data structures were indexed beyond the end of their data. We had tested night after night after night. Lesson learned.

After I moved to UAB, we ran into a similar problem. Except this time we used a second computer to generate commands and such to simulate 64 simultaneous users, to make sure no surprised lurked. We could leave this running all night as opposed to trying to find 64 users to sit at a terminal all night and do different things. Not good enough. The "load simulator" was not random enough, even though I had a number of random delays. Load simulator would run fine, real users crashed the system as load picked up. Couple of race conditions in an interrupt handler that took really unusual conditions before they would cause a problem.

Cray Blitz. Solid chess program, in 1993-1994 it was over 25 years old already. The parallel search stuff had been done back in 1983. So 11 years of never screwing up in a game. UNTIL we moved to the new Cray YMP in the late 80's. That machine had both 8 processors, AND a clock about twice as fast as the original Cray. When we used it in the ACM tournament, we almost lost a game if not for fortuitous debugging code. A race condition let the search go much deeper than intended. Deep enough to run out the end of arrays indexed by ply, which should never have exceeded 64. We "added kings" due to that problem, and CB was NOT happy with multiple kings. But some debugging code left in by accident looked at the board after an iteration, and if it found something wrong, it simply restored the position to what it was at the start of the search to allow debugging to continue. Our first hint was when we starting seeing things like Kg1-h1, Kb8-a8, Kf4-f5, etc. We were wondering where all the kings came from. The race condition had never exposed itself, mainly due to 2 or 4 processors making it very unlikely. But with 8, suddenly it was much more likely than unlikely the bug would appear. Even though the program had been tested over and over, had played in a dozen ACM events, etc. Race conditions are nasty, hard to find, and often lay dormant until the worst possible time.

As Dijkstra said, "testing can show the presence of bugs, but never the absence of bugs."

I should add, ALL of the above bugs were fixed and tested. But they were there in spite of due diligence in testing. Ed has an odd definition of "no bugs". I would assume ALL of the above would qualify as "bug-free" since the bugs were definitely fixed. But that is not _my_ definition of bug-free. I simply would refer to them as "after testing, no known bugs exist." Which is a LONG way from saying "after testing, NO bugs exist."

I never tolerate bugs of any kind. And I also do NOT write code that is buggy by nature. But I, like most everyone else, realize that our code can STILL contain undiscovered bugs no matter how much we test.

BTW, here's a funny (but true) story. You decide whether it was a bug or not. When I was working on my computer science degree, a friend of mine was one year ahead of me, but we worked together all the time. One day he came in smiling and I asked him "what's with the cheshire cat grin?" (reference to Alice in Wonderland.) He replied "I've found a source of funding that is easy to generate. I asked "explain?"

He said OK, I joined the book of the month club. Ever heard of those? I said yep, you join, every month they send you a book that you can keep and pay for, or else send it back. He said "right". He said that was step 1. Then he asked "Do you remember in the COBOL class back in the summer we discovered that the "zone punch" (an over punch over the least significant digit" was the way to enter a negative number on the IBM systems using packed decimal numbers, which were about all that were used in Data Processing at the time.)

He said "OK, here's what happened. When the books arrived, they came with an IBM-type punched card (holes in 'em but blank otherwise), no printing. I simply ran back to the card punch room, and ran it through the 029 interpreting keypunch machine. Which made a duplicate AND printed the character in each column of punches along the top of the card. I discovered that it contained my account number (as shown on mail that came from the club from time to time.) It also contained the title of the book. AND the price. I took the card, put it in a keypunch machine, turned printing off so there would be no indication of a change, and then I over punched the "zone code" to make the price of the book negative. I kept the book, sent the card back to the club, and next month I received (a) a new book and (b) a check for the amount of the book I had supposedly bought the previous month. But since it was negative, thanks to that zone overpunch, they gave me a credit balance and refunded it no questions asked. I then sold the book to friends for ½ price and ended up making 150% of the price of the book.

Obviously that was a pretty stupid approach. But it was the late 60's. No online data bases. No huge customer databases when 7mb disks were expensive and small. Bug or not? program worked exactly as it was supposed to. Nobody ever considered that the price could come back as a negative number by a clever programmer.

Revealing that you describe an act of uttering a forged document and fraud for pecuniary advantage as "bug", "funny" and "by a clever programmer". That sort of white collar crime is a serious imprisonable offence. It's not at all clever, it's just forgery using a punch card writer rather than a pen or a printer. "Source of funding, easy to generate" is a serial offence.

Obviously, in your world "programmers, friends of yours" can do no wrong. Even in the face of clear fraud. You even boast about it. Character assessment and ethics not your strong point.

Design flaw? Just one of those things?

Criminal activity.

I did tell him "this is going to haunt you. They are not going to remain idiots forever." It did and the last I heard before he graduated was that they were "in negotiations about this." They ended up hiring him. So the story had a happy ending. Bugs are bugs.

Yeah, right. It's the book publishers fault, for having a "bug". Actually they had a criminal user, one of your friends. Did you try the same thing yourself?

There have been bugs since early life started on planet earth. Bugs remain today. Both software and real bugs. No future in sight where they will no longer exist, until Sol becomes a super-nova.

You REALLY one of those that can't see the forest for the trees, eh? I was NOT commenting on the guy that exploited the hole. I was commenting on the hole. JUST the hole. I'd bet 99% of the people here would realize that and also realize that there was no judgement about the student that pulled this off. NONE.

Would you not call hacking into web sites to expose user data or obtain credit card numbers as "criminal activity?"

well, like most things, it depends. One thing for sure, doing it to obtain pecuniary advantage for oneself is almost certainly fraud. I’m surprised you call it funny and blame the bank (in 1968).

MANY bugs allow criminal activity. So what? They are STILL bugs produced at some point in the process from inception to delivery.

The issue was "was this a software bug?" was it a design flaw? was it an incomplete/ambiguous specification document? How you get off into criminal statutes and such is a complete mystery.

its not a bug at all. The system accepted a credit note, as it should do with credit notes, and applied the sum to the customers account, as it should. It was discovered later, with a full audit trail back to your idiot criminal friend, as it should have been, and as is standard accounting practice.

Can't see where I "boasted about it" at all. I explained a pretty serious issue. That was in that software for 4-5 years. Testing did not expose it. Walk-throughs did not catch it. Design reviews did not catch it. Specification validation did not catch it.

because it wasn’t a bug. It accepted an apparently lawful credit note, rightly. Then it later discovered by normal auditing procedures that there had been a fraud. Everything worked as ut should.

No wonder every conversation with you degenerates into an argument.

if you make dumb comments and speak praisingly about fraud, then hardly surprising.

It is apparently what YOU want...

[bob]

As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release.

In writing Amoeba, as a lone individual, I spent 99.9% of my time testing and 0.1% writing code. I have limited financial resources, but I have an invaluable resource: time.

I also have a lot of time. But I also have access to huge computing resources. I have literally played many millions of games during testing, also. And in spite of all the effort, and all the games played, I STILL find the occasional bug. And will continue to do so based on experience. I'm sure Ed/Chris will just say I am a lousy programmer and they can do much better. I'd first like to see their program(s) that can beat mine; and then have time to carefully examine their programs for the presence of bugs.

It's easy to talk a good game.

Hilarious. Talk is all you do. Volume in inverse proportion to reality. Most if not all with one intention of bigging yourself and belittling everybody else.

MUCH harder to actually write that bug-free code. And convince anybody that is actually IS bug-free.

Well, Ed was convincing in the market place and in the demand for his chess engine code by electronics manufacturers, who by definition, are going to be very concerned that they are taking on bug-free code else they end up having to bin thousands of manufactured units. Me likewise, We get voted for by hard earned money, contracts for supply and capital wanting to invest, over a very extended period. You?

This the same Ed that someone just reported a bug in one of his Mephisto versions he wrote? The program that played an illegal move? The program that then promptly crashed? That Ed.

Glad you like living in never-never-land where if you imagine it, it becomes true. You are the only person on the planet that sells software with no bugs. I assume you don't need version numbers since the first version shipped is perfect? You might check the number of versions of ProDeo. Or ANY other chess program other than your perfect code...

[bob]

How can this be? Ed writes bug-free code?

I hope not in fact I stopped working on playing strength in 2016 after the realization that during the years a bug slipped in that made the result of matches unreliable. For example, a cutechess match of 10,000 games could give 51.8% with a LOS of 100% while running it again it could produce a negative < 50% score. That's insanity.

I recently fixed the bug, now I only have to redo approximate 7-8 years of promising candidate engine changes

Happy now?

Why would you lie about that? You and Chris have already claimed to write bug-free code. So how can bug-free code have a bug? Why did it take so long to find it? Didn't you properly test it.

You begin to get the point I have been talking about? Your story above is not surprising. Crafty has been running with no changes and no errors of any kind for 3+ years (since I retired). I recently found a significant race condition that no one had seen (or at least not noticed). This is common. It is expected.

Software engineering texts often compare software to automobiles. Except automobiles are far more accurately specified, last minute changes are not allowed without tons of review and simulations. And yet they still roll off the assembly line with unknown issues. Do you measure every single component in all directions to verify it fits? Do you test the strength of every bolt? If you do, you destroy them, so you could never sell a car (torque to yield bolts are but one example). If we can't build something with zero defects, how can we WRITE something with far more parts (lines of code) with zero defects.

Nobody wants bugs. Everybody has 'em. And there doesn't seem to be a way to solve this.

[bob]

Personally, I have NEVER released a piece of code with known bugs. Or with even suspected bugs (testing simply continued to try to track them down.) That being said I have certainly released things with unknown bugs.

The most painful to me was in the 1970's. I had written about 100,000 lines of assembly language for the Xerox Sigma 9. Deep in the operating system. Main goad was to move ALL of the character-oriented hardware stuff out of the operating system and out into an attached computer to offload all the interrupt handling (each character types produced two interrupts, one for when the character was received in the Sigma 9 and one for when it was echoed back to the user. I had tested and tested this code, night after night, 10pm to 8am. For several months. We decided to "go live" on the campus computer on a Monday to test in a real user environment before handing it over to Telefile (which had taken over the xerox computer product line.

Damn thing was booted at 8am, and by 8:15 am it had crashed. A couple more attempts, a couple more crashes, couple more HUGE core dumps and off I went to test. Problem was simple. We had 64 serial lines on the I/O processor. We had only 32 on the original sigma 9 hardware. Nobody notice when we generated the operating system (anyone remember the term sysgen or system generation from the early IBM days?) my helper had left the number of serial connections at 32, which dictated the size of lots of data structures. Meanwhile, back at the ranch, the code for the front-end processor was set to 64 serial lines. When the 33rd user logged in, big problem as things started to get overwritten as data structures were indexed beyond the end of their data. We had tested night after night after night. Lesson learned.

After I moved to UAB, we ran into a similar problem. Except this time we used a second computer to generate commands and such to simulate 64 simultaneous users, to make sure no surprised lurked. We could leave this running all night as opposed to trying to find 64 users to sit at a terminal all night and do different things. Not good enough. The "load simulator" was not random enough, even though I had a number of random delays. Load simulator would run fine, real users crashed the system as load picked up. Couple of race conditions in an interrupt handler that took really unusual conditions before they would cause a problem.

Cray Blitz. Solid chess program, in 1993-1994 it was over 25 years old already. The parallel search stuff had been done back in 1983. So 11 years of never screwing up in a game. UNTIL we moved to the new Cray YMP in the late 80's. That machine had both 8 processors, AND a clock about twice as fast as the original Cray. When we used it in the ACM tournament, we almost lost a game if not for fortuitous debugging code. A race condition let the search go much deeper than intended. Deep enough to run out the end of arrays indexed by ply, which should never have exceeded 64. We "added kings" due to that problem, and CB was NOT happy with multiple kings. But some debugging code left in by accident looked at the board after an iteration, and if it found something wrong, it simply restored the position to what it was at the start of the search to allow debugging to continue. Our first hint was when we starting seeing things like Kg1-h1, Kb8-a8, Kf4-f5, etc. We were wondering where all the kings came from. The race condition had never exposed itself, mainly due to 2 or 4 processors making it very unlikely. But with 8, suddenly it was much more likely than unlikely the bug would appear. Even though the program had been tested over and over, had played in a dozen ACM events, etc. Race conditions are nasty, hard to find, and often lay dormant until the worst possible time.

As Dijkstra said, "testing can show the presence of bugs, but never the absence of bugs."

I should add, ALL of the above bugs were fixed and tested. But they were there in spite of due diligence in testing. Ed has an odd definition of "no bugs". I would assume ALL of the above would qualify as "bug-free" since the bugs were definitely fixed. But that is not _my_ definition of bug-free. I simply would refer to them as "after testing, no known bugs exist." Which is a LONG way from saying "after testing, NO bugs exist."

I never tolerate bugs of any kind. And I also do NOT write code that is buggy by nature. But I, like most everyone else, realize that our code can STILL contain undiscovered bugs no matter how much we test.

BTW, here's a funny (but true) story. You decide whether it was a bug or not. When I was working on my computer science degree, a friend of mine was one year ahead of me, but we worked together all the time. One day he came in smiling and I asked him "what's with the cheshire cat grin?" (reference to Alice in Wonderland.) He replied "I've found a source of funding that is easy to generate. I asked "explain?"

He said OK, I joined the book of the month club. Ever heard of those? I said yep, you join, every month they send you a book that you can keep and pay for, or else send it back. He said "right". He said that was step 1. Then he asked "Do you remember in the COBOL class back in the summer we discovered that the "zone punch" (an over punch over the least significant digit" was the way to enter a negative number on the IBM systems using packed decimal numbers, which were about all that were used in Data Processing at the time.)

He said "OK, here's what happened. When the books arrived, they came with an IBM-type punched card (holes in 'em but blank otherwise), no printing. I simply ran back to the card punch room, and ran it through the 029 interpreting keypunch machine. Which made a duplicate AND printed the character in each column of punches along the top of the card. I discovered that it contained my account number (as shown on mail that came from the club from time to time.) It also contained the title of the book. AND the price. I took the card, put it in a keypunch machine, turned printing off so there would be no indication of a change, and then I over punched the "zone code" to make the price of the book negative. I kept the book, sent the card back to the club, and next month I received (a) a new book and (b) a check for the amount of the book I had supposedly bought the previous month. But since it was negative, thanks to that zone overpunch, they gave me a credit balance and refunded it no questions asked. I then sold the book to friends for ½ price and ended up making 150% of the price of the book.

Obviously that was a pretty stupid approach. But it was the late 60's. No online data bases. No huge customer databases when 7mb disks were expensive and small. Bug or not? program worked exactly as it was supposed to. Nobody ever considered that the price could come back as a negative number by a clever programmer.

Revealing that you describe an act of uttering a forged document and fraud for pecuniary advantage as "bug", "funny" and "by a clever programmer". That sort of white collar crime is a serious imprisonable offence. It's not at all clever, it's just forgery using a punch card writer rather than a pen or a printer. "Source of funding, easy to generate" is a serial offence.

Obviously, in your world "programmers, friends of yours" can do no wrong. Even in the face of clear fraud. You even boast about it. Character assessment and ethics not your strong point.

Design flaw? Just one of those things?

Criminal activity.

I did tell him "this is going to haunt you. They are not going to remain idiots forever." It did and the last I heard before he graduated was that they were "in negotiations about this." They ended up hiring him. So the story had a happy ending. Bugs are bugs.

Yeah, right. It's the book publishers fault, for having a "bug". Actually they had a criminal user, one of your friends. Did you try the same thing yourself?

There have been bugs since early life started on planet earth. Bugs remain today. Both software and real bugs. No future in sight where they will no longer exist, until Sol becomes a super-nova.

You REALLY one of those that can't see the forest for the trees, eh? I was NOT commenting on the guy that exploited the hole. I was commenting on the hole. JUST the hole. I'd bet 99% of the people here would realize that and also realize that there was no judgement about the student that pulled this off. NONE.

Would you not call hacking into web sites to expose user data or obtain credit card numbers as "criminal activity?"

well, like most things, it depends. One thing for sure, doing it to obtain pecuniary advantage for oneself is almost certainly fraud. I’m surprised you call it funny and blame the bank (in 1968).

MANY bugs allow criminal activity. So what? They are STILL bugs produced at some point in the process from inception to delivery.

The issue was "was this a software bug?" was it a design flaw? was it an incomplete/ambiguous specification document? How you get off into criminal statutes and such is a complete mystery.

its not a bug at all. The system accepted a credit note, as it should do with credit notes, and applied the sum to the customers account, as it should. It was discovered later, with a full audit trail back to your idiot criminal friend, as it should have been, and as is standard accounting practice.

Can't see where I "boasted about it" at all. I explained a pretty serious issue. That was in that software for 4-5 years. Testing did not expose it. Walk-throughs did not catch it. Design reviews did not catch it. Specification validation did not catch it.

because it wasn’t a bug. It accepted an apparently lawful credit note, rightly. Then it later discovered by normal auditing procedures that there had been a fraud. Everything worked as ut should.

No wonder every conversation with you degenerates into an argument.

if you make dumb comments and speak praisingly about fraud, then hardly surprising.

It is apparently what YOU want...

OK, now you have crossed over from never-never-land to completely-stupid-land. Point by point:

First, did I try this? No.

Second, you claim I "praised him." Did you see where I explicitly told him "this is going to bite you." How is THAT praise. Just in your broken mind. Feel free to show me any praise for this obviously bad act.

Third, a program that accepts input that should never have been accepted is not a bug? The company certainly thought it was. The definition of robust code:

Robust programming is a style of programming that focuses on handling unexpected termination and unexpected actions. It requires code to handle these terminations and actions gracefully by displaying accurate and unambiguous error messages. These error messages allow the user to more easily debug the program.

You don't think this was an "unexpected action?" If a chess program accepted a1-a1, would you think that was not a bug? You seem to just make this crap up as you go, a veritable "crap generator." Whomever wrote that piece of code should have checked to make sure the number was positive, and less than some upper bound. Seen quite a few bank/credit-card bugs where someone gets a million dollar charge (or credit). This was a bug, plain and simple. Robust programs aren't clobbered by bad input. They might still crash for other reasons, but nothing input as data will cause any unexpected behavior or crashes. Hard to talk with someone that uses completely bizarre definitions of words that everyone else considers something else.

Here's the definition that almost all of use for the term "software bug":

A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. ... A program that contains many bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy (defective).

Any other definition is imaginary.

Now try again, it is only YOUR reputation you are damaging with this nonsense. Shoot, quote my example above and create a poll here to see how many think it is a bug and how many don't. I would suspect one no, from you. I don't think even Ed would go down that path.

[Rebel]

This the same Ed that someone just reported a bug in one of his Mephisto versions he wrote? The program that played an illegal move? The program that then promptly crashed? That Ed.

You judge without knowing the facts.

Not a bug, a compromise between manufacturer and the programmer, they knew idiotic positions that never occur in real games could cause trouble.

When they consulted me to work for them they (Hegener & Glaser) offered me 4kB of RAM (4096 bytes), I said, no I need 8Kb RAM and explained why, that contrary to other programmers I created all pseudo legal moves on each ply in the tree. And they said, do it like everybody else, 4Kb it is. On which I said, then I can't give you the program you want. And so it ended. Later they changed their mind and gave me 8Kb and we made the deal.

So they knew, no bug.

Poor you.

[Ovyron]

Well, if Micromax is an example of bug-free software due to its simplicity, can't it be expanded? Like, re-purposed? Add code that makes it stronger without introducing bugs, how big can a program be while remaining bug-free? Bugfreemax?