Error in 49G/50g ROM Rev 1.19-6 to 2.10-7

[Gerald H]

FPTR2 ^CK1Z

supposedly converts hexadecimals to zints but in fact errors out.

[3298]

Huh, interesting. I took a look into ROM 2.15 with Nosy, same issue. I'm tempted to just declare it a documentation error (since we're all using "Programming in SysRPL" by Kalinowski and Dominik, not a HP-made reference; as such it has some mistakes, even after the book's own errata are taken into account), but there's a little more to it:

^CK1Z (and by extension ^CK2Z and ^CK3Z, which both call ^CK1Z) uses CK&DISPATCH0 to handle various types of input with different pieces of code. So far, so normal - the handlers it associates with the dispatch codes for reals and strings are entries documented as converting reals and strings (respectively) to ZINTs: ^R>Z and ^S>Z. The only remaining dispatch code is the one for ZINTs (so the types HXS and BINT are unhandled, contrary to documentation), which makes sense since you would expect already-existing ZINTs to not get rejected. (Unlike CK&DISPATCH1, CK&DISPATCH0 won't auto-convert ZINTs to reals; you wouldn't want this lossy and inefficient there-and-back conversion anyway.)

But then it gets weird. The handler given for ZINTs is ^H>Z, which you would expect is for converting a HXS to ZINT, given the name. The documentation is a little ambiguous on it, but it definitely talks about HXS too.
But that command doesn't convert them! I looked at the code for a while and concluded that it sanity-checks the structure of a ZINT instead: non-empty digit string, no digits that would be invalid for BCD (i.e. hexadecimal digits >9), a leading 0 or 9 (the latter indicates a negative number), and not just a 9 by itself.
Since it doesn't check the prolog, you can stuff a HXS in there (they also consist of prolog, then length field, then digit string, just like a ZINT), but the results will most likely be incorrect or an error.

So here we have a command with plain wrong documentation, and another where it's at least severely misleading.

While we're at it, I recently encountered another issue: psh1& and psh1&rev have the same stack diagram (meta1 meta2 ob -> ob&meta1 meta2), though it's only correct for psh1&. psh1&rev attaches ob to the end of meta2 instead of the start (meta1 meta2 ob -> meta1&ob meta2). Just mentioning it before I forget about it again.

---

Actually, back to the problem of converting a HXS to ZINT: with ^H>Z disqualified, there doesn't seem to be a direct way to convert these types. Going via reals is easy but lossy, because e.g. #FFFFFFFFFFFFFFFFh (that's 2^64-1, the largest number the UserRPL compiler and many HXS-handling commands support) won't fit into the 12 digits of a real, so we'll have to 1) eat the loss of precision, 2) declare that HXS are not a supported input type, 3) chop them into pieces to convert separately, or 4) write our own conversion function in Saturn ASM.

[Gerald H]

You might, 3298, be interested in this programme:

https://www.hpmuseum.org/forum/thread-40...EXADECIMAL