The bug is mine, and will not exist before J8.04 or thereabouts.
I did everything I could think of to ensure that this kind of thing
wouldn't happen. I put in debug code to monitor the constant areas
continually and I eyeballed each individual case where the address of a
data area was used to ensure that the area was made safe before the
write. I found lots of places, but to tell you the truth I am a little
surprised it took this long for a problem to surface, and it makes me
think there aren't too many more latent.
It took so long to be seen because it fails only when you apply 0&p: to
a boolean atom.
Henry Rich
On 2/26/2022 12:31 PM, Ian Clark wrote:
I was just about to beg to withdraw my facetious last post in favor of a
slightly more profound one.
Raul got in first, but was kind enough to refrain from pointing out that (0
p: 0) is a perfectly sensible phrase to use, in its guise of (0&p:
i.1000000) which offers a good way to generate the Sieve of Eratosthenes.
(But which, incidentally, doesn't trigger the 0=1 bug.)
0=1
0
0 p: 0
1
0=1
1
Henry calls it the Mother Of All Bugs. Gerry Weinberg (in *The Psychology
of Computer Programming*) calls it the World's Most Expensive Bug. A
certain large (unnamed) enterprise in the 1960s spent millions of dollars
replacing suspect hardware and spending tens of thousands of man-hours to
fix a rare but potentially disastrous glitch. A memory location labelled
ONE could, in certain circumstances, assume the value 2.
It may be an urban legend, but it was well-known to the (non-financial)
programming community in the 1980s, when I was giving courses in Human
Factors, also Software Engineering, where it was one of the foundation
myths of the topic. It may have inspired *const* in C++, not to mention the
101 different names for 0 and 1 you see in C++ code. Not to mention
spawning languages like ADA, which aim to force typical runtime bugs to
appear at the compilation stage.
Perhaps we all deserve a pat on the back for finding it so quickly, and not
spending a million bucks to do so. But *was* it found so quickly? In the
form Henry exhibits it, it happens in j902 and j901 too. It may go back
even earlier. I have an old machine running j602 somewhere in the junk
room: I ought to dig it out and check.
In which case we might ask: why hasn't it been reported before? What
unsuspected damage has it been wreaking over the years? Have people died
when they reached 79 because their pacemakers were coded in J? And what
about those top-secret apps in the White House with lines of code like
(NUKE_MOSCOW=:0) ? What if Russia found out? (…or perhaps they have?!!)
But I'm getting facetious again. At least I hope so.
On Sat, 26 Feb 2022 at 15:55, Raul Miller <[email protected]> wrote:
On Sat, Feb 26, 2022 at 10:48 AM Ian Clark <[email protected]> wrote:
Really when you think of it, anyone asking if 0 is a prime number
deserves
all they get. :-)
This kind of thing was why I was suggesting a way of running a
checksum on J's constants, not long ago.
That said, I also remember recently getting a file name error using
control-L in the jqt editor (in other words: loading a temp file). I
wonder if we can find the trigger for that one?
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
