On Fri, 26 Oct 2018 07:07:58 -0500, Tom Marchant wrote: > >>"Machine independent". The data type was not "halfword", but "int", defined >>as [-32768,32767] and stated that the effect of assigning a larger value was >>undefined. Debugger should have enforced. > >It should have enforced that the effect of assigning a larger value was >undefined? >What does that mean? > A conscientious designer should avoid the "undefined" dodge. The effect should be specified as to generate an error.
C, because of Bad History, makes the effect of a (signed int) overflow undefined. This allows the processor to substitute an (unspecified) in-range value, or to take other action, such as to throw SIGFPE. I prefer the latter, but I'm at odds with prevailing art. C implementations that I know require execution with fixed-point overflow disabled in the program mask. (I haven't checked XL C.) ASSEMBLER-LIST has recorded bitter dissent about validity of immediate operands. LHI ,65535? Someone has argued intensely for support of LHI ,2x'FF'. DWIM? Ugh! If I view SORT as having an unordered set as input and an ordered array as output, "original order" is meaningless. If the input is a physical sequential data set, that implies an order that, with EQUALS, can be a lowest-order key. (I can (barely) imagine a programmer's using the original sequence as a key, but not the lowest order.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
