Thou shalt have no other gods before the ANSI C standard 1411

That portability could be enhanced at zero cost by making the fifth parameter ("l") a "sizet" instead of an "unsigned int". Otherwise, people using a 64-bit architecture and trying to process more than 4 GB of data may have a problem.

One version of the DEC-Compaq-HP compiler for Alpha under OSF-1 (or Tru64) had a 128-bit long long. I think that such an architecture could make that part of the code fail:

because with such a machine, you get 0 or 1 in f, instead of 0 or -1(*).

This can be corrected, still at zero runtime-cost, with a proper choice of the int64 and uint64 types. I suggest replacing the five #define near the top of the file with this:

* ============================================================ *

#if CHARBIT != 8 #error We need 8-bit bytes #endif typedef unsigned char uchar;

typedef int int32; typedef unsigned int uint32; #else typedef long int32; typedef unsigned long uint32; #endif

typedef long int64; typedef unsigned long uint64; #else typedef long long int64; typedef unsigned long long uint64; #endif* ============================================================ *

Note that this will not make the code fully portable to the 36-bit la-la-land(**), but at least it should provide better support for Alpha machines.

How about a Java version ? Java guarantees 32-bit int, 64-bit long and sign-extension on right-shifting. It also features big integer arithmetics (in java.math.BigInteger) in standard clbuttes, which are automatically available even on very old Java implementations (including those in Netscape 4 and Internet Explorer 5).

I can make a Java equivalent of poly1305gmpxx.cpp if you need it but do not know Java enough. A more optimized version (using only "int" and "long", not "BigInteger") is also doable (the port should be easy because your buttumptions about 32-bit integers and so on are quite close to the JVM specification).

--Thomas lovein

(*) Right-shifting a negative value yields an "implementation-defined" result. Most C compilers do sign-extension, because most hardware implements such sign-extension. I don't know how to make some code which does not rely on that buttumption, and yet compiles to as efficient code. In this situation, I recommend a simple comment about the fact that the code buttumes sign-extension.

(**) English is not may mother language, and I think I may be missing some of the gist related to that "la-la-land" term. Some people seem to find it pejorative and offensive. Is it a hidden reference to some clbuttical literary work ?