As I understand it, the following statement:
print using "<0>#,##", 1234
outputs:
1,234
which makes sense; leading zeros (of which there are none) and five characters available for the five characters we want to output. Another statement which I understand is:
print using "<0>#####,#######", "12345678"L
which outputs:
00,012,345,678
again, makes sense given my understanding of the formatting characters; 14 characters available for the digits, commas, and leading zeros.
What I don't understand is how:
print using "<0>####,#######", "12345678"L
can output:
00,012,345,678
Surely that's one too many leading zeros? Surely it should be:
0,012,345,678
I can see that sometimes a leading zero is added over and above the length specified, if otherwise the output would start with a leading comma, such as in this example:
print using "<0>###,#######", "12345678"L
which produces
0,012,345,678
despite seemingly not reserving enough space. But is the previous example a bug in Basic, or am I missing something here?
Looks like bug. It adds a bonus leading zero when <0> and the thousands separator play together. That <0> should count for 1 position.
It reproduces for me under Basic 1.3 (OpenVMS 8.3) and 1.7-000 on OpenVMS 8.4. I used smaller test values to avoid creating confusion/interaction with the max integer size of "Ten digits of precision for LONG integers" Basic Ref manual.
Btw.. good use of the "nnn"L. That pre-empts any (implied) conversion discussion. I would move the comma, to the end or start of the ### sequence to avoid implying a specific position.
As a (but-uggly) workaround, you might use FORMAT$ ( val, format-string ). It has the same problem, but the program will get a change to tweak the result.
$ cre tmp.bas
1 OPTION TYPE = EXPLICIT, SIZE = INTEGER LONG, CONSTANT TYPE = INTEGER
print using "<0>###,", 1234
print using "<0>###,", 123
print using "<0>###,", 12
print using "<0>###", 1234
print using "<0>###", 123
print using "<0>###", 12
Exit
$ bas tmp
$ link tmp
$ run tmp
1,234
00,123
00,012
1234
0123
0012