On Tue, 22 Dec 2009, Hans Hagen wrote:

Aditya Mahajan wrote:

...

On Mon, 21 Dec 2009, Reinhard Kotucha wrote:

...

Dear Sirs, I wrote a tiny program which calculates the checksum of a file. It should provide the the same result as md5sum(1), but it doesn't.

It's possible that there are problems with line endings. But I must admit that I don't remember whether I added the binary flag to the function install_file(...) before Tomek tested it. However, the fact that md5sum.tlu and md5sum(1) provide different results is not what I expect.

Any idea?

Something seems to be wrong with the library:

For example

$echo -n "test" | md5sum 098f6bcd4621d373cade4e832627b4f6 -

but

print(md5.sumhexa("test")) gives

0944483cd90a293923c8244520132de1

strange, as on my machine (vista) it gives

098f6bcd4621d373cade4e832627b4f6

Hmm... I am using linux 64 bit and This is LuaTeX, Version beta-0.47.0-2009121815 Aditya

2009/12/21 Hans Hagen :

...

Something seems to be wrong with the library:

For example

$echo -n "test" | md5sum 098f6bcd4621d373cade4e832627b4f6  -

but

print(md5.sumhexa("test")) gives

0944483cd90a293923c8244520132de1

strange, as on my machine (vista) it gives

098f6bcd4621d373cade4e832627b4f6

Same here on WinXP with luatex beta-0.40.6-2009110118 & beta-0.46.0-2009112716. I don't know what gives. I did test Reinhard's installer on the same machine and with the same binaries and it failed on checksums back then. Cheers, Tomek

On 22 December 2009 Hartmut Henkel wrote:

seems to be a 32/64 bit issue. After sprinkling the md5.c code with 32 bit MASKs (see diff) luatex indeed gives the correct 098f6bcd4621d373cade4e832627b4f6 on an x86_64 AMD debian Linux PC.

Many thanks to everybody who helped to find the bug, and to Hartmut, who provided a fix. Hartmut, did you consider already to inform the Lua developers. I think that this problem should be fixed upstream. I surmise that Lua is supposed to work on 16 bit systems as well, hence I suppose that the code has to be revised anyway. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

On 22 December 2009 Hartmut Henkel wrote:

seems to be a 32/64 bit issue. After sprinkling the md5.c code with 32 bit MASKs (see diff) luatex indeed gives the correct 098f6bcd4621d373cade4e832627b4f6 on an x86_64 AMD debian Linux PC. Unclear which MASK made it, but i guess it's in the rotate().

Though this problem will not exist in future versions of luatex, it seems that I have to wait a few years until I can enable the MD5 code again. I simply commented it out for the time being. Not everybody has a recent version of luatex. There are systems like CentOs or Debian which still support old stuff (no package updates, only security fixes). The MD5 stuff is not essential in my script, but I'd like to use it whenever possible. Currently it's commented out. luatex provides some TeX primitives: \luatexversion \luatexrevision \luatexdatestamp However, I'm not using luatex but texlua and couldn't figure out how to access these variables in lua. If this isn't supported already, what about providing a luatex table? luatex.version luatex.revision luatex.datestamp ...and maybe even more: luatex.author, luatex.license... :) If I can evaluate, for instance, luatex.datestamp, I can enable MD5 checks in my script on sytems where it works. That would be nice. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

On 18 January 2010 Aditya Mahajan wrote:

On Mon, Jan 18, 2010 at 6:35 PM, Reinhard Kotucha wrote:

...

If I can evaluate, for instance, luatex.datestamp, I can enable MD5 checks in my script on sytems where it works. That would be nice.

How about

if (md5.sumhexa("abcdefghijklmnopqrstuvwxyz") == "c3fcd3d76192e4007dfb496cca67e13b") then -- md5 works... do what you want else -- fallback for md5 not working end

Hi Aditya, this is a brilliant idea. Thank you very much. I adopted my file accordingly. It's availble from http://tug.org/~kotucha/getnonfreefonts I simply skip the MD5 checks if they don't work. On my 64-bit Gentoo system I get: Installing texmf/scripts/getnonfreefonts/getnonfreefonts.pl ... [done] Installing texmf/doc/man/man1/getnonfreefonts.1 ... [done] Installing texmf/doc/man/man1/getnonfreefonts-sys.1 ... [done] Fixing File Permissions ... [done] However, Gentoo allows me to execute 32-bit binaries if I put bin/i386-linux into $PATH instead of bin/x86_64-linux. Then I get: Installing texmf/scripts/getnonfreefonts/getnonfreefonts.pl ... [done] Installing texmf/doc/man/man1/getnonfreefonts.1 ... [done] Installing texmf/doc/man/man1/getnonfreefonts-sys.1 ... [done] md5sum: 028f96580787066ac0084251e2ccc915 getnonfreefonts.pl ... [ok] md5sum: f850d910dd96ee27cecdb3772047d247 getnonfreefonts.1 ... [ok] md5sum: fb2b0f7699db8e627d4e26b730e94928 getnonfreefonts-sys.1 ... [ok] Fixing File Permissions ... [done] This is exactly what I want to achieve. Thanks again.

This way, you also protect yourself from bugs in the future versions of luatex :-)

There will be no bugs in future versions of luatex. I obviously know Taco better than you. :) Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------