#378 bif ARG gives error message for whole number


In the two-liner REXX program:

/**/ numeric digits 100; parse version x; say x
say arg(4444555577,'omitted')

displays this output:

REXX-Regina_3.6(MT) 5.00 31 Dec 2011
2 +++ say arg(4444555577,'omitted')
Error 40 running "D:\11.rex", line 2: Incorrect call to routine
Error 40.12: ARG argument 1 must be a whole number; found "4444555577"

This first argument is clearly a whole number according to the current DIGITS.
____________________________________________ Gerard Schildberger


  • Mark Hessling

    Mark Hessling - 2012-09-04

    This behaviour is consistent with ooRexx and the ANSI standard. The standard forces NUMERIC DIGITS to 9 for all BIFs that require a whole number as an argument.
    As another example:
    numeric digits 100
    say copies('*',1000000000)

    also results in error 40.12; invalid whole number

    I agree that this behaviour doesn't seem consistent with Rexx's philosophy of "no unexpected surprises", so I've raised this issue with the ANSI standard with the ANSI committee members.

  • Gerard Schildberger


    doesn't get error 40.12. Regina tries, but fails with a different error after trying to execute the statement.
    Note that Regina can acquire 1.2 billion bytes (via 100k chunks at a time), but not all at once, apparently.
    At least, not with this method ( via the LEFT bif). Also note that R4 successfully executes the above statement.

    I think I know what is really causing the problem, and I'll get back to this issue later after doing more research.
    What would be a good forum for what I find? Someone to E-mail? Put it in the "suggestion box"?

    Also, note that:

    say substr(c,1234567894,1)

    works correctly on Regina. I suspect other BIFs also work with larger-than-life numbers.

    I agree completely that the other behavior is inconsistent with REXX's philosophy
    (don't use the principle of least astonishment --- at least, that's one of my interpretations of it anyway).

    If the BIF is assuming 9 digits, than the error message should say that's the real digit limitation the bif is using,
    not the obvious one that is right before the failing statement.

    I think the original document (probably) intended to say (or meant) that at least 9 digits of precision would be
    used regardless of the current NUMERIC DIGITS setting. ... But, it didn't. It's not too late to fix that.
    Extending (or fixing) this problem won't break any code, at worst, instead of getting a SYNTAX error, the
    programmer will get what is expected, or possibly, run out of virtual storage (which would be a normal thing to
    expect if the result would be a humongous string).

    I don't see any problem with extending the definition(s) for numeric digits used for BIFs. R4 already ignores
    this, the max imposed limit for many BIFs. It's not a solid ceiling. I see this the same way Regina looked at
    some of the earlier limitations, the 50 character variable names, number of MAX/MIN arguments, length of
    string limits, length of clauses, number of continued statements, number of digits supported, and whatnot.
    ____________________________________________ Gerard Schildberger

  • Gerard Schildberger

    Also, I suspect that in 1979 (or thereabouts), nobody in their right mind could think that
    any REXX BIF would need more than 9 digits, as CMS had a limit of a mere 16 megabytes
    for virtual memory, of which CMS chewed up a third of a meg or so, maybe less.
    Who'd thunk that 2 gigabytes would be the norm? TSO REXX programmers sure hit
    that limit when using the STORAGE bif and virtual address got that big. I also suspect
    that the 2 gigabyte limit will be lifted when 64-bit systems will be the norm, and the C
    limitations will also be raised.
    ____________________________________________________ Gerard Schildberger


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks