[64bit] type conflict for INT32

[Ken Brown]

On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 11:56, Ken Brown wrote:
>> /usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains
>>
>>    typedef long INT32
>>
>> Aside from the fact that this produces a confusing name for a 64-bit
>> data type
>
> Per the comment there: "INT32 must hold *at least* signed 32-bit values"
> (emphasis mine).
>
>> it conflicts with /usr/include/w32api/basetsd.h, which has
>>
>>    typedef signed int INT32
>>
>> This causes a problem for the build of emacs-w32.
>
> Fortunately, the code doesn't seem to care about consistency in this
> type.  Even on Linux, when itself is compiled for x86-64 this will be a
> 64-bit signed type, but when the header is used in conjunction with X11
> headers (which have a typedef int INT32;), jmorecfg.h uses that and
> skips its own typedef.
>
> So it would seem we could do the same with w32api:
>
> === BEGIN ===
> --- /usr/include/jmorecfg.h
> +++ /usr/include/jmorecfg.h
> @@ -161,4 +161,6 @@
>   #ifndef XMD_H            /* X11/xmd.h correctly defines INT32 */
> +#ifndef _BASETSD_H_        /* w32api defines this in basetsd.h */
>   typedef long INT32;
>   #endif
> +#endif
>
> === END ===
>
> It does mean that Win32API (or X11, for that matter) headers must be
> #include'd before <jpeglib.h>.  Before I spin a new release, could you
> test if this works with emacs?

Yes, it works.  Thanks.

Ken