Hi all, $ cat foo.lua print( string.format("%08s","1100101")) (so a one liner, nothing fancy). On my Mac: $ luatex foo.lua 01100101 on my Linux machine: $ luatex foo.lua 1100101 (where is the leading 0??) Mac: $ luatex --version This is LuaTeX, Version beta-0.79.1 (TeX Live 2014) (rev 4971) Linux: $ luatex --version This is LuajitTeX, Version beta-0.79.1 (TeX Live 2014/dev) (rev 4972) How can this difference show up? Is this something from "jit"? Thanks Patrick
On 12/17/2014 3:55 PM, Patrick Gundlach wrote:
Hi all,
$ cat foo.lua print( string.format("%08s","1100101"))
(so a one liner, nothing fancy).
On my Mac:
$ luatex foo.lua 01100101
on my Linux machine:
$ luatex foo.lua 1100101
(where is the leading 0??)
Mac: $ luatex --version This is LuaTeX, Version beta-0.79.1 (TeX Live 2014) (rev 4971)
Linux: $ luatex --version This is LuajitTeX, Version beta-0.79.1 (TeX Live 2014/dev) (rev 4972)
How can this difference show up? Is this something from "jit"?
on windows i get no leading 0 ... I think %s has no 'leading whatever' spec, only a - for justification so I guess that interpreting the number is library specific (apart from the fact that lua has some wrapper code around format and jit probably overloads some) just for fun i tried \ctxlua{print(string.format("%a8i",1100101))} which on linux gives invalid option '%a' to 'format' and on windows 0x1.0c9450p+208i whatever that means so one has to be real careful with what goes in front of a length specifier Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
on windows i get no leading 0 ... I think %s has no 'leading whatever' spec, only a - for justification so I guess that interpreting the number is library specific (apart from the fact that lua has some wrapper code around format and jit probably overloads some)
you're right: this is most likely due to the underlying libc... from the linux sprintf(3) manpage: 0 The value should be zero padded. For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions, the converted value is padded on the left with zeros rather than blanks. If the 0 and - flags both appear, the 0 flag is ignored. If a precision is given with a numeric conversion (d, i, o, u, x, and X), the 0 flag is ignored. For other conversions, the behavior is undefined. and from the mac: `0' (zero) Zero padding. For all conversions except n, the converted value is padded on the left with zeros rather than blanks. If a precision is given with a numeric conversion (d, i, o, u, i, x, and X), the 0 flag is ignored. Thanks! Patrick (who enjoys writing portable Go programs more and more....)
participants (2)
-
Hans Hagen -
Patrick Gundlach