Hi all, On Fri, Dec 2, 2011 at 8:25 AM, Michael Jackson <[email protected]> wrote: > (VERY Red faced). > That is on OS X that there is a difference: > > 32 Bit: > sizeof(int): 4 > sizeof(long): 4 > sizeof(long long): 8 > > 64 Bit > sizeof(int): 4 > sizeof(long): 8 > sizeof(long long): 8 > > Again, sorry for the confusion. Trying to keep it all straight is confusing. > Over the years I have just stayed away from "long" where absolutely possible.
Windows is LLP64, most other platforms are LP64. http://en.wikipedia.org/wiki/64-bit (scroll down to 64-bit data models) http://www.unix.org/version2/whatsnew/lp64_wp.html >>>> (ie just inverting the order from INT - LONG - LONG LONG to LONG LONG - >>>> LONG - INT.) In this way ssize_t is of type long and there is no conflict >>>> with ImageMagick. And I think there is no real change in HDF5 too, since >>>> sizeof(int)==sizeof(long). The problem is that ssize_t appears in our public API, yet is not standard C (it's POSIX). Typically, in a project that started on Linux that is being ported to Windows, the Linux project will implement a hard-coded work-around, as we have in HDF5. The problem comes when these work-arounds collide, as they have here. Configure and build systems like CMake wouldn't even help here since there are essentially two choices, neither of which is standard and either of which will make someone's upstream software unhappy. Unfortunately, although changing the order of the #defines solves the problem for ImageMagick, it will cause the same problem for anyone who expected the former typedef. Since so much software exists that builds on HDF5 and uses the public headers it is very likely that we would break something, possibly in an important customer, so we've decided to leave the behavior as it is. As a work-around, you'll probably have to hack up the header file for one of the packages. The real solution is to remove non-ANSI (or non-HDF group specific) types from the public API to avoid this type of problem in the future. Since this would amount to an API-breaking change, it will have to wait for a major version change (HDF5 1.10.0) to be considered. I will enter an issue in our bug-tracking system so that it'll be on our radar in the future. Thank you for bringing this to our attention! Cheers, Dana _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
