crafty (or MSVC) bug

[jwes]

The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in

segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));

to

segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));

appears to fix the problem.

[bob]

The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in

segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));

to

segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));

appears to fix the problem.

I am working on a fix for this brain-dead decision by Microsoft. Going to try to use the new standard types header file.

[CThinker]

The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in

segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));

to

segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));

appears to fix the problem.

In Windows, long is always 32-bits. All compilers for Windows abide by this (GCC, LCC, ICC, MSVC).

The correct code would be to use size_t instead of long or longlong.

[bob]

The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in

segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));

to

segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));

appears to fix the problem.

In Windows, long is always 32-bits. All compilers for Windows abide by this (GCC, LCC, ICC, MSVC).

The correct code would be to use size_t instead of long or longlong.

Or the more modern int64_t/int32_t in stdint.h... I am trying to test this on MSVC now. Works perfectly on linux and gives on the ability to declare 8/16/32/64 bit values, signed or unsigned, without the compiler doing something goofy such as long = 32 bits on a 64 bit machine, as in windows.

[UncombedCoconut]

What about intptr_t? That seems like what is meant, and I've read that even Microsoft ships stdint.h (finally!!).

[bob]

What about intptr_t? That seems like what is meant, and I've read that even Microsoft ships stdint.h (finally!!).

Depends on what is being done. For pointers, that is the right type. For "long" integers, int64_t is the right one.

[jdart]

Arasan uses the intrinsic _aligned_malloc for MSVC, and posix_memalign for Linux. Unfortunately though there does not seem to be an equivalent for Mac OS.

[bob]

Arasan uses the intrinsic _aligned_malloc for MSVC, and posix_memalign for Linux. Unfortunately though there does not seem to be an equivalent for Mac OS.

And posix_memalign() is not present on all linux distributions since some still use older ones. I used that for a while, but decided to write my own to make things completely portable.