Patch: Fix ssize_t definition on windows

David Cournapeau davidc at enthought.com
Thu Jul 4 06:55:37 PDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130704/595b3e12/attachment.html>


More information about the llvm-commits mailing list