Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500 I noticed some time ago that HLASM fails to check properly for overflow during USING calculations, which in my opinion is a bug in HLASM. However, it's not just a matter of checking each calculation for overflow, because intermediate calculations could overflow (depending on the order in which they are done) even when the final result is valid, and rejecting that with an overflow indication could cause problems for existing programs.
By ignoring overflow and just letting calculations wrap round, the current implementation tolerates all cases where the final result is valid but fails to detect some cases which should have been rejected. I think that conceptually the result should be as if HLASM did the intermediate calculations using a larger field (for example using 63-bit signed arithmetic) then checked whether the final result was in the valid range for a 31-bit signed offset, giving an overflow indication if not. It may well be possible to implement that rule without actually using a larger field. Jonathan Scott IBM Hursley, UK > Pieter Wiid <[email protected]> wrote: > > > > Your USING should be USING X,R2 > > Then, you get this with HLASM (z/OS 2.2) > > > > 00002 1 R2 EQU 2 > > 00003 2 R3 EQU 3 > > 000000 00000 00004 3 FOO CSECT > > FFFFFF 4 X EQU X'7FFFFFFF' > > R:2 FFFFFF 5 USING X,R2 > > 000000 4130 2002 00001 6 LA R3,-X > > > > Ugh - yep - you're right. > > And, that's a difference from us, we get this: > > 7FFFFFFF 4 X EQU X'7FFFFFFF' > 7FFFFFFF 5 USING X,R2 > 00000000 0000 0000 00000000 6 LA R3,-X > ** DASM028E Invalid displacement > ** DASM435I Record 6 in t2.asm > > that means, for this bright Monday morning - I'll have to enter a bug. > > - Dave Rivers - > -- > [email protected] Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com
