Patch: Fix ssize_t definition on windows

Aaron Ballman aaron at aaronballman.com
Thu Jul 4 07:13:55 PDT 2013


With minor tweaks, applied in 185627

~Aaron

On Thu, Jul 4, 2013 at 9:55 AM, David Cournapeau <davidc at enthought.com> wrote:
>
>
>
> On Thu, Jul 4, 2013 at 2:47 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> On Thu, Jul 4, 2013 at 9:31 AM, David Cournapeau <davidc at enthought.com>
>> wrote:
>> > Hi,
>> >
>> > This simple patch fixes ssize_t definition (that was defined as being 4
>> > bytes on windows 64), fixes both cmake and configure build (I only
>> > tested
>> > cmake build though).
>> >
>> > This patch allowed me to build llvmpy on windows 64 bits (python defines
>> > its
>> > own ssize_t, that conflicted with the wrongly defined one in llvm
>> > headers).
>> >
>> > I was not sure how to submit a patch, let me know if I need to do it
>> > differently,
>>
>> The patch generally looks good to me, but:
>>
>> > From b4929b4a19969b391048d2c74b2e8b2401c83109 Mon Sep 17 00:00:00 2001
>> > From: David Cournapeau <cournape at gmail.com>
>> > Date: Thu, 4 Jul 2013 13:43:04 +0100
>> > Subject: [PATCH] BUG: fix ssize_t definition on windows.
>> >
>> > ssize_t must be big enough to address a pointer, so it needs to be 64
>> > bits on 64 bits.
>> > ---
>> >  include/llvm/Support/DataTypes.h.cmake | 6 +++++-
>> >  include/llvm/Support/DataTypes.h.in    | 7 ++++++-
>> >  2 files changed, 11 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/llvm/Support/DataTypes.h.cmake
>> > b/include/llvm/Support/DataTypes.h.cmake
>> > index 7484abd..f52b1d6 100644
>> > --- a/include/llvm/Support/DataTypes.h.cmake
>> > +++ b/include/llvm/Support/DataTypes.h.cmake
>> > @@ -101,7 +101,11 @@ typedef short int16_t;
>> >  typedef unsigned short uint16_t;
>> >  typedef signed char int8_t;
>> >  typedef unsigned char uint8_t;
>> > -typedef signed int ssize_t;
>> > +#if defined(_WIN64)
>> > + typedef __int64 ssize_t;
>> > +#else
>> > +  typedef long ssize_t;
>> > +#endif
>>
>> Why the change from signed int to long?
>
>
> Mostly to be consistent with SSIZE_T:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx#SSIZE_T
>
> long vs int on windows only matters for 'weird' architectures that are
> obsolete, I guess, so that's that argument is mostly red herring, and int
> would obviously work as well.
>
> David
>>
>>
>> >  #ifndef INT8_MAX
>> >  # define INT8_MAX 127
>> >  #endif
>> > diff --git a/include/llvm/Support/DataTypes.h.in
>> > b/include/llvm/Support/DataTypes.h.in
>> > index b9fb48a..6acd679 100644
>> > --- a/include/llvm/Support/DataTypes.h.in
>> > +++ b/include/llvm/Support/DataTypes.h.in
>> > @@ -98,7 +98,12 @@ typedef short int16_t;
>> >  typedef unsigned short uint16_t;
>> >  typedef signed char int8_t;
>> >  typedef unsigned char uint8_t;
>> > -typedef signed int ssize_t;
>> > +#if defined(_WIN64)
>> > + typedef __int64 ssize_t;
>> > +#else
>> > +  typedef long ssize_t;
>> > +#endif
>>
>> Here as well.
>>
>> ~Aaron
>
>
>
>
> --
> blog: http://cournape.wordpress.com
> code: https://github.com/cournape
> twitter: @cournape



More information about the llvm-commits mailing list