Which I think proves what bunnyman said.
That this now says my code is perfect, is laughable.
But that's not what it's saying: it's only saying that 'strict' (as it were) couldn't find anything wrong with it. No more no less. The same as when Perl decides your program can be compiled, it is no guarantee that it will run correctly. It only guarantees that it will start to run. If you're lucky, it won't get an execution error before it ends.
Anecdote Alert:
In 1989 I was working on an editor for a system that had its roots in the beginning of the 70's. It used what you would now call a "subfile" system, in which named blocks could contain code and other data.
The maximum size of such a block (which was commonly used as a subroutine) was 8K. Each line consisted of characters followed by a null byte. Once, long before, it was decided that 2 consecutive null bytes would indicate end of data: this saved having to keep the "length" of data somewhere externally. (Remember, in the early 80ies a hard-disk had the size of a dish-washer and was able to store several Megabytes!)
Of course, this posed a problem for empty lines: so an empty line was basically a space with a null byte. So an empty line took 2 characters.
This made the editor quite a bit more complex, but that was of course offset with faster compilation (which was on-demand per subroutine).
While working this new screen-based editor (rather than the line-based editor that it used to be), I found a bug. If a block contained 8191 bytes of code (one less than what could fit in the block), it would still allow you to create a new line. But an empty line took 2 characters! So this would cause an overflow and an execution error.
Unfortunately, I didn't find this problem myself, but my client did. But looking at the code, I realised that that part had basically been lifted from the older version. And lo and behold, that version also contained that error.
The previous version of that editor had been in production more than 7 years at that time. And that editor was based on what had run on the mainframe before that, so it would easily add another 10 years of production to it.
So why didn't anybody find that bug before? Well, since this happened in the editor, you would lose any changes you had made to that block. And I don't know about you, but I'm not able to reproduce code exactly a next time in a create process. So the next time the code would be different and the problem would not occur (you only needed one extra character to be typed to have the block fill up "properly").
I guess this episode taught me that any non-trivial program is never without bugs, no matter how long it has run in production.
It also taught me that you need to create a test-suite: a properly made test-suite would have found this problem immediately. Now, in those days, there were basically no system resources to do this. Current systems do have those resources. And I can only recommend that they be used!
Liz
In reply to Re: Re: Re: Re: Re: to strict or not to strict
by liz
in thread to strict or not to strict
by castaway
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |