Talk:Short-circuit evaluation: Difference between revisions

Line 96:
:Your last sentence reminds me of a compiler trick with gfortran: I wrote a little program to see how a bad program could crash (changing the value of a constant, IIRW). Without optimisation, it crashed, with optimisations, it didn't. It's perfectly correct in regard of the Fortran standard: such a program has unspecified behaviour, thus crashing or not according to a compiler option is as "valid" as blowing up the computer altogether or anything else. But I still feel it's not fair, and I consider this a bug. At least, it's incredibly misleading. This behaviour disappeared with the -fnoipa-cp compiler option. [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 22:32, 20 July 2015 (UTC)
 
::Ahem. I've done that too, and with intent. The IBM1620's Fortran II compiler allowed only simple expressions for array indexing, (''const''*''variable'' +- ''constant'') and I wanted (I + J) inside a READ statement's list and there was some reason why I couldn't use an implicit DO-loop as in (A(K),K = I + J,...) or similar - possibly because that was a facility introduced in Fortran IV. Anyway, as you will have guessed, I found I could write A(J + 12345) after calling subroutine ZAP(12345,I) and suddenly, the storage set aside to hold the constant would contain ... something else. This would not work for simple constants such as zero that on some systems might be developed by in-line code. Naturally, there must be no other usage of a constant 12345 that expects it to have its proper value. On the IBM1130 this would ''not'' work, because although the constant would be damaged, constant offsets in array indexing were merged with the base address of the array and so vanished at run time. And anyway, array indexing now allowed arbitrary expressions. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 03:34, 7 June 2017 (UTC)
1,220

edits