Issues with porting C++ code to a 64-bit platform • Hacker News Board

Re: Issues with porting C++ code to a 64-bit platform

#31

Post by MichaelSalib » Mon, Apr 01, 2013, 8:36 PM UTC

dschatz wrote: post #20

MichaelSalib wrote: post #17

Earlier quoted context omitted.

Actually a 63 bit number and a 1 bit sign flag Not true. Modern architectures use 2s-complement rather than an explicit sign bit to represent integers. If you use a sign bit, there are two different zeros (positive and negative) but the range of positive numbers is exactly as large as the range of negative numbers. With 2s-complement, there's only one zero and the range of negative numbers is larger (by one) than the…

In 2s complement, the most significant bit is the sign bit. In fact all valid C integer representations have a sign bit.

This is wrong.

Take an integer value x. Flip the sign bit. Do you now have the value -x? On a 2s complement architecture, you do not. In 2s complement, you have to flip all the bits and add one to get -x.

Re: Issues with porting C++ code to a 64-bit platform

#32

Post by peripetylabs » Mon, Apr 01, 2013, 8:38 PM UTC

Every C++ developer should read this. I've done research on integer arithmetic, which includes some of the pointer arithmetic issues discussed here. This is one of the best article I've seen on the subject so far. Thanks for sharing.

This is a small detail, but in C99 you can use the "zu" format specifier for size_t typed arguments of the printf/scanf functions; is this also true for C++? Another tip is to use the PRI* and SCN* macros defined in the C header ( for C++):

http://pubs.opengroup.org/onlinepubs/009604599/basedefs/intt... http://en.cppreference.com/w/cpp/header/cinttypes

Re: Issues with porting C++ code to a 64-bit platform

#33

Post by CamperBob2 » Mon, Apr 01, 2013, 8:52 PM UTC

to3m wrote: post #27

CamperBob2 wrote: post #23

Earlier quoted context omitted.

I'm not convinced that the explosion of specialized types benefits anyone but language lawyers. Some of us actually have work to do, and NULL should mean NULL. Using '0' for null pointers as mpyne suggests is less desirable because it robs the reader of context ("Is this a pointer being compared to 0, or a numeric type?") That could be worked around with Hungarian notation, but some would argue that the cure is worse…

But before nullptr, NULL didn't portably mean "a null pointer". It meant "0", just as if you'd typed in "0" rather than "NULL". The language doesn't really give the library writer much choice in the matter! (Defining NULL as "((void *)0)" would at least give it an inherently pointer type, but it would be terribly inconvenient to use.) This is the whole reason for nullptr in the first place.

Right, I'm saying that as long as they were going to redefine NULL as part of the C++ standard anyway, they should have redefined it as ((void *) 0). That would be portable, at the expense of breaking code that used NULL in integer comparisons.

Re: Issues with porting C++ code to a 64-bit platform

#34

Post by cjensen » Mon, Apr 01, 2013, 9:02 PM UTC

Item #7 is incorrect. You can't make a union of a pointer and an integer type or a union between a number of chars and a larger int type and expect valid results ever -- the optimizer will rip your head off.

Re: Issues with porting C++ code to a 64-bit platform

#35

Post by asynchronous13 » Mon, Apr 01, 2013, 9:07 PM UTC

I happen to be working on some 32/64 bit code right now, and this article has some very useful tips. Pretty sure they mixed up arguments on their memset() call in section 3 though:

  memset(values, ARRAY_SIZE * sizeof(size_t), 0);

should be:

  memset(values, 0, ARRAY_SIZE * sizeof(size_t));

That would not be a fun bug to track down.

Re: Issues with porting C++ code to a 64-bit platform

#36

Post by plorkyeran » Mon, Apr 01, 2013, 9:07 PM UTC

yew wrote: post #12

mpyne wrote: post #3

I had issue #2 (varags) bite me once on a C function where a NULL pointer was used as a sentinel. In C++ we normally use '0' as the name of the null pointer, as C's NULL macro ((void*)0) gives compilation errors normally (though it would have worked here). And of course, who knows what the NULL macro is defined to in C++ mode, it could be plain '0' or a compiler-specific type. With varargs '0' simply translates to in…

Huh. I'd always thought C++ shared C's definition of NULL, but looking I see that it doesn't. What a weird thing to change. At least they've added some safety with nullptr_t.

C's definition would be incredibly unpleasant to use with no implicit conversions from void * . If you had to write things like int * x = (int *)NULL I'm pretty sure everyone would just use 0.

Re: Issues with porting C++ code to a 64-bit platform

#37

Post by peripetylabs » Mon, Apr 01, 2013, 9:09 PM UTC

16s wrote: post #10

But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1). I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens: #include #include i…

One way to avoid loss of precision in the conversion is to check if the number of digits in the integer is larger than the constant DBL_DIG (defined in ) -- numbers with less digits than that constant can be safely converted to the 'double' type and back.

Re: Issues with porting C++ code to a 64-bit platform

#38

Post by vinkelhake » Mon, Apr 01, 2013, 9:17 PM UTC

CamperBob2 wrote: post #33

to3m wrote: post #27

Earlier quoted context omitted.

But before nullptr, NULL didn't portably mean "a null pointer". It meant "0", just as if you'd typed in "0" rather than "NULL". The language doesn't really give the library writer much choice in the matter! (Defining NULL as "((void *)0)" would at least give it an inherently pointer type, but it would be terribly inconvenient to use.) This is the whole reason for nullptr in the first place.

Right, I'm saying that as long as they were going to redefine NULL as part of the C++ standard anyway, they should have redefined it as ((void *) 0). That would be portable, at the expense of breaking code that used NULL in integer comparisons.

C++ doesn't have an automatic conversion from void* to T* so having NULL as ((void*)0) wouldn't have worked.

Re: Issues with porting C++ code to a 64-bit platform

#39

Post by CamperBob2 » Mon, Apr 01, 2013, 9:41 PM UTC

vinkelhake wrote: post #38

CamperBob2 wrote: post #33

Earlier quoted context omitted.

Right, I'm saying that as long as they were going to redefine NULL as part of the C++ standard anyway, they should have redefined it as ((void *) 0). That would be portable, at the expense of breaking code that used NULL in integer comparisons.

C++ doesn't have an automatic conversion from void* to T* so having NULL as ((void*)0) wouldn't have worked.

True, but again, the whole problem is all of these weird, random changes and exceptions that only a small subset of programmers can keep in their heads. If you're going to go down that path, you should pick safe weird, random changes and exceptions.

In this case, they should have turned NULL into a first-class keyword that would parse as an invalid pointer of any given type, and called it "done." In the original C spec NULL wasn't supposed to be a pointer at all -- it was just a more polite way to write "zero." As endless Internet debates have shown, it turns out that it would have been better to reserve it for use in pointer expressions.

Re: Issues with porting C++ code to a 64-bit platform

#40

Post by thwest » Mon, Apr 01, 2013, 9:53 PM UTC

peripetylabs wrote: post #37

16s wrote: post #10

But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1). I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens: #include #include i…

One way to avoid loss of precision in the conversion is to check if the number of digits in the integer is larger than the constant DBL_DIG (defined in ) -- numbers with less digits than that constant can be safely converted to the 'double' type and back.

Note that DBL_DIG is the number of decimal digits that can be a 9. If the max integral value storable in a double is 4,000,000, DBL_DIG would only be 6. It is a conservative limit.