Wrong value returned by SYS$FAO

[John Gillings]

Additional 2c...

The parameters to $FAO[L] are actually polymorphic. The type and mechanism depend on the corresponding directive in the control string. So there's no universally correct definition in any language for all possible combinations of directives and actual parameters. "ANY BY REF" is general enough to prevent most compilers from complaining, but you'll often need to override the mechanism with the language specific syntax, depending on the exact directive you're using.

[John Travell]

Noted, but the problem is that BASIC does not appear to offer the programmer any control on whether arguments are presented as 'by ref' or 'by value'.
When I tried specifying 'by value' in the service call I got compilation errors because the mode of the argument did not match the entry in the function.
While I feel this should be corrected, I wonder how many people it would affect. Who else but me is still writing code in BASIC...!

[Peter Barkas]

Yep, still using DEC BASIC ;-)

The V1.6 definition is the same as V1.5.

As was said earlier it is probably quite unusual for a BASIC programmer to use SYS$FAO as PRINT USING and FORMAT$ are normally used for formatting output.

Also this is certainly not the first time that definitions in BASIC$STARLET have been incorrect. This is not a serious problem as HELP system_services $FAO, for example, shows the correct definition and it is not that onerous to type it in.

[John Travell]

At least I am not alone... :-)

I cannot see how format$ can cut the mustard when it comes to converting a hexadecimal value into an ascii representation of the hex value.
i.e. hex 1F2E3D4C becomes ascii "1F2E3D4C"
Basic converts it to DECIMAL before formatting the numeric value into ascii.

For this task I do not know of anything other than one of the SYS$FAO family of services that has any chance of getting it right.
JT: