Replace INT32 with a new internal datatype (JLONG)
These days, INT32 is a commonly-defined datatype in system headers. We
cannot eliminate the definition of that datatype from jmorecfg.h, since
the INT32 typedef has technically been part of the libjpeg API since
version 5 (1994.) However, using INT32 internally is risky, because the
inclusion of a particular header (Xmd.h, for instance) could change the
definition of INT32 from long to int on 64-bit platforms and thus change
the internal behavior of libjpeg-turbo in unexpected ways (for instance,
failing to correctly set __INT32_IS_ACTUALLY_LONG to match the INT32
typedef-- perhaps as a result of including the wrong version of
jpeglib.h-- could cause libjpeg-turbo to produce incorrect results.)
The library has always been built in environments in which INT32 is
effectively long (on Windows, long is always 32-bit, so effectively it's
the same as int), so it makes sense to turn INT32 into an explicitly
long datatype. This ensures that libjpeg-turbo will always behave
consistently, regardless of the headers included at compile time.
Addresses a concern expressed in #26.
diff --git a/jcdctmgr.c b/jcdctmgr.c
index 73f3ea4..cef4b5e 100644
--- a/jcdctmgr.c
+++ b/jcdctmgr.c
@@ -302,15 +302,15 @@
for (i = 0; i < DCTSIZE2; i++) {
#if BITS_IN_JSAMPLE == 8
if(!compute_reciprocal(
- DESCALE(MULTIPLY16V16((INT32) qtbl->quantval[i],
- (INT32) aanscales[i]),
+ DESCALE(MULTIPLY16V16((JLONG) qtbl->quantval[i],
+ (JLONG) aanscales[i]),
CONST_BITS-3), &dtbl[i])
&& fdct->quantize == jsimd_quantize)
fdct->quantize = quantize;
#else
dtbl[i] = (DCTELEM)
- DESCALE(MULTIPLY16V16((INT32) qtbl->quantval[i],
- (INT32) aanscales[i]),
+ DESCALE(MULTIPLY16V16((JLONG) qtbl->quantval[i],
+ (JLONG) aanscales[i]),
CONST_BITS-3);
#endif
}