Use a typedef instead of a #define for ssize_t with MSVC

[tkelman]

I was seeing the define for ssize_t cause some collisions and compilation errors in Julia (with MSVC) due to libuv also using this type. I think a typedef would be preferable? Could potentially use intptr_t for this instead, but I'm not sure exactly which versions of MSVC would support that.

[stevengj]

A typedef also potentially collides.

Maybe wrap the #define in an #ifndef?

[tkelman]

Will try it, but I don't think that'll work since the libuv headers aren't checking ssize_t, they're checking _SSIZE_T_ which they set themselves.

[tkelman]

The full failure, for reference, is

 /d/code/msys64/home/Tony/julia/deps/libuv/compile cl -nologo -MD -Z7 -TP "-DJL_
SYSTEM_IMAGE_PATH=\"../lib/julia/sys.ji\"" -DJULIA_TARGET_ARCH=x86-64 -D_WIN32_W
INNT=0x0502 -I../support   -I/d/code/msys64/home/Tony/julia/deps/libuv/include -
I/d/code/msys64/home/Tony/julia/usr/include  -DLIBRARY_EXPORTS -DUTF8PROC_EXPORT
S -DNDEBUG -c julia_extensions.c -o /d/code/msys64/home/Tony/julia/src/flisp/jul
ia_extensions.o
julia_extensions.c
d:\code\msys64\home\tony\julia\deps\libuv\include\uv-win.h(27) : error C2628: 'i
ntptr_t' followed by '__int64' is illegal (did you forget a ';'?)
make[2]: *** [/d/code/msys64/home/Tony/julia/src/flisp/julia_extensions.o] Error
 2
make[2]: Leaving directory `/d/code/msys64/home/Tony/julia/src/flisp'
make[1]: *** [flisp/libflisp.a] Error 2
make[1]: Leaving directory `/d/code/msys64/home/Tony/julia/src'
make: *** [julia-src-release] Error 2

We could either use the same _SSIZE_T_ defines as libuv, or #undef ssize_t in Julia's code, but both seem a little fragile to me.

[stevengj]

If we typedef our own ssize_t wouldn't that also conflict with another header that has the same typedef?

This is a general problem with defining our own symbols with standard names — other libraries are bound to use the same names.

[stevengj]

I'm not sure I understand the problem. If libuv is #defining only _SSIZE_T_, why would that conflict with ssize_t?

[tkelman]

If we typedef our own ssize_t wouldn't that also conflict with another header that has the same typedef?

I would think it might, but it apparently wasn't an issue at least in this limited case of utf8proc and libuv. Maybe if the typedefs are consistent enough, the compiler doesn't complain?

If libuv is #defining only _SSIZE_T_, why would that conflict with ssize_t?

See https://github.com/JuliaLang/libuv/blob/abcbb0c22faa527c427e1ea6b55f073836b26f69/include/uv-win.h#L26-L30 for precisely what libuv is doing. It's using _SSIZE_T_ as an include guard around a typedef for ssize_t. That typedef is a compilation error if included after utf8proc.h has #defined ssize_t.

[tkelman]

As an alternative, we could pick a less-likely-to-collide name, something like utf8proc_ssize_t and use that everywhere.

[tkelman]

That avoids the MSVC issue, and Travis and Appveyor look happy with it.

[stevengj]

Picking a new name seems like the best practice. But we should also probably define utf8proc_uint8_t etcetera to be consistent?

[tkelman]

Perhaps. I was wanting to avoid extra work to fix problems that I haven't had, but I could go even more nuts with grep and sed if needed. MSVC has been gradually improving in its C99 compliance recently, so many of these typedefs aren't needed with modern versions, but laziness probably isn't a good enough reason to not at least leave in the possibility of support for old versions. The Python 2 community will be continuing to use MSVC 2008 for several more years at the very least.

[tkelman]

Done. This latest commit seems like overkill to me, take it or leave it.

Note that I didn't touch the contents of bench, which AFAICT won't build right now with a non-C99 compiler anyway. I have little interest in dealing with that at the moment.

[tkelman]

Okay to merge this, or is that second commit too ugly?

[stevengj]

Should be okay to merge.

[tkelman]

Thanks!

[tkelman]

Presumably we can merge master into the release-1.2 branch at some point.