Hobart Spitz wrote: >the latter..., or something even milder, I just don't know what. Getting >into the habit of ignoring warnings is not a great idea, and it means >questions for the next person that has to look at your code.
Thanks for taking my point as intended, sir. Always risky these days...! Absolutely, ignoring warnings is a Very Bad Habit. My first official (computing) language was PL/I (well, PL/C): I sat in on my dad's university course the summer of 1975, after my 8th grade. He taught me to examine and hopefully eliminate any warnings. At the time, I thought PL/I was anal about such things; now that I have to deal with C, I long for PL/I. I feel like in C there are lots of warnings that "everybody ignores" (often by telling the compiler not to issue them), whereas in PL/I I don't recall being unable to eliminate every one of them legitimately. I like the idea of PROTECT/UNPROT instructions*. Seems like the cleanest way to do it to me. So, we'll have this later this year, right? :) ...phsiii *I wasn't sure of the right term for "a thing that the assembler looks at but doesn't actually generate code"; Google found me IBM pages that refer to USING as an "instruction", so I would take PROTECT/UNPROT to be in the same category. Happy to be corrected, as ever.
