<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 7, 2022 at 9:58 AM Hans Hagen <<a href="mailto:j.hagen@xs4all.nl">j.hagen@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/7/2022 9:15 AM, luigi scarso wrote:<br>
> Hi,<br>
> here<br>
> <a href="https://github.com/latex3/latex2e/issues/775" rel="noreferrer" target="_blank">https://github.com/latex3/latex2e/issues/775</a> <br>
> <<a href="https://github.com/latex3/latex2e/issues/775" rel="noreferrer" target="_blank">https://github.com/latex3/latex2e/issues/775</a>><br>
> there is an issue about the portability of the lua bytecode .<br>
> Suggestions ?<br>
> In any case, the patches are  not for TeXLive 2022 .<br>
Even with a patsh (not sure which one i only see akira mentioning the <br>
size of a blob) it is not guaranteed to be portable and formats are <br>
already not portable (endian wise) so why bother ... just make a new <br>
format, right? We've dealt with it for > 15 years so ... anyway, Karl <br>
doesn't mind if nothing changes so we're not really in a hurry ... <br>
indeed not for upcoming.<br>
<br>
Btw, can't windows 32 be compiled with 64 bit pointers? Does the same <br>
issue occur with the mingw binaries?<br></blockquote></div><div><br></div><div><br></div><div>Dunno... the scope of this thread is also to collect info about  the current status of fmt portability (for luatex only).</div><div><br></div><div>In web2c.pdf :</div><div>4.3.3 Hardware and memory dumps<br>By default, memory dump files are generally sharable between architectures of different<br>types; specifically, on machines of different endianness (see Section “Byte order” in GNU<br>C Library). (This is a feature of the Web2c implementation, and is not true of all TEX<br>implementations.) If you specify ‘--disable-dump-share’ to configure, however, memory<br>dumps will be endian-dependent.<br>   The reason to do this is speed. To achieve endian-independence, the reading of memory<br>dumps on LittleEndian architectures, such as PC’s and DEC architectures, is somewhat<br>slowed (all the multibyte values have to be swapped). Usually, this is not noticeable, and<br>the advantage of being able to share memory dumps across all platforms at a site far<br>outweighs the speed loss. But if you’re installing Web2c for use on LittleEndian machines<br>only, perhaps on a PC being used only by you, you may wish to get maximum speed.<br>   TEXnically, even without ‘--disable-dump-share’, sharing of .fmt files cannot be guar-<br>anteed to work. Floating-point values are always written in native format, and hence will<br>generally not be readable across platforms. Fortunately, TEX uses floating point only to<br>represent glue ratios, and all common formats (plain, LATEX, AMSTEX, . . . ) do not do any<br>glue setting at .fmt-creation time. Metafont does not use floating point in any dumped<br>value at all.<br>   Incidentally, different memory dump files will never compare equal byte-for-byte, because<br>the program always dumps the current date and time. So don’t be alarmed by just a few<br>bytes difference.<br>   If you don’t know what endianness your machine is, and you’re curious, here is a little C<br>program to tell you. (The configure script contains a similar program.) This is from the<br>book C: A Reference Manual, by Samuel P. Harbison and Guy L. Steele Jr. (see Appendix B<br>[References], page 55).<br>      main ()<br>      {<br>        /* Are we little or big endian? From Harbison&Steele.               */<br>        union<br>        {<br>          long l;<br>          char c[sizeof (long)];<br>        } u;<br>        u.l = 1;<br>        if (u.c[0] == 1)<br>          printf ("LittleEndian\n");<br>        else if (u.c[sizeof (long) - 1] == 1)<br>          printf ("BigEndian\n");<br>        else<br>          printf ("unknownEndian");<br><br>          exit (u.c[sizeof (long) - 1] == 1);<br>      }<br><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">luigi<br></div></div>