3 ms·

> Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds

> Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds data can be ‘working’, yet read from or write to unallocated memory, but then break when a new OS release changes the memory allocator or changes the size of some allocations. Another example are broken checks for features. If, instead of checking whether the OS or CPU supports feature ‘foo’, you check for ‘version ≥ magic_number’, assuming every OS/CPU will after that will support the feature, your program code can stop working when that assumption turns out to be incorrect. The code was broken all the time, though.

diggan 3y ago
Both those cases sound like code that was correct at the time of writing, with the assumptions at the time in mind. Which turned into incorrect code when the environment changed, but that doesn't mean the code itself wasn't correct at the time, for the intended environment. I guess I'd reserve "broken code" for code that doesn't work at all, I wouldn't use it to describe code that worked in one environment but not in another, unless purposefully built for the second of course.
- Someone 3y ago
  That’s a very loose definition of “correct code”. If you write out of bounds or occasionally read memory you didn’t allocate and how do you know you get away with it, so that you can declare the code “correct”? Your program may crash only once in a thousand years. In my book it still would be incorrect as soon as it breaks the interface contract of the API, even if it never crashed or misbehaved. Also, in your definition, you can’t complain if a program stops running after even a tiny OS upgrade it wasn’t “purposely built for”, for example because it that didn’t exist yet at the time the program was compiled.

diggan 3y ago

Both those cases sound like code that was correct at the time of writing, with the assumptions at the time in mind. Which turned into incorrect code when the environment changed, but that doesn't mean the code itself wasn't correct at the time, for the intended environment. I guess I'd reserve "broken code" for code that doesn't work at all, I wouldn't use it to describe code that worked in one environment but not in another, unless purposefully built for the second of course.

Someone 3y ago
That’s a very loose definition of “correct code”. If you write out of bounds or occasionally read memory you didn’t allocate and how do you know you get away with it, so that you can declare the code “correct”? Your program may crash only once in a thousand years. In my book it still would be incorrect as soon as it breaks the interface contract of the API, even if it never crashed or misbehaved. Also, in your definition, you can’t complain if a program stops running after even a tiny OS upgrade it wasn’t “purposely built for”, for example because it that didn’t exist yet at the time the program was compiled.