On Wed, 30 Oct 2013 07:29:27 -0500, John McKown wrote: > http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security > ><quote> >Compilers: can�t live with �em, can�t live without �em - at least not if >you write code for a living. Compilers are great at taking your hand >crafted human-readable program, translating it into machine code and, in >the process, optimizing it so it runs as efficiently as possible. >Sometimes, though, as new research from MIT points out, in their zeal to >optimize your code, compilers can go too far and remove code that they >shouldn�t, which can make the system or application more vulnerable. >... ></quote> > >I don't know if this applies to z/OS or other z compilers. But I thought it >was at least somewhat interesting. I never consider that the compiler, in >its zeal, might do something like this. > If a construct is specified to have undefined semantics, I's expect that an allowable interpretation is "no-operation". Surely the compiler should be allowed to remove no-ops. The flaw is in the compiler's toleration of undefined constructs. Of course, no programmer should rely on undefined constructs for security, but does the compiler issue any warning whatever?
Pascal (I remember only vaguely) required that the processor be able (at the programmer's option?) to treat implementation-dependent constructs in the same manner as errors. But that specification was left to the accompanying documentation, which was allowed to state that errors are not reported. FORTRAN (at least early) likewise specified that any implemention is free to choose the behavior of constructs not described in the specification. I consider all the above misapplications of Postel's Robustness Principle. (I'm not sure that there are any proper applications.) Our minds have collectively contaminated by the pervasive liberality of HTML renderers. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
