11–20 of 45 posts
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…
At least they've added some safety with nullptr_t.
One thing he doesn't mention is "-fPIC", I've been bitten by this bug many times: "please re-compile with PIC enabled and try again"!
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…
Heh. Sometime around '94 I helped Southwestern Bell Telephone with that during the 16 bit to 32 bit transitions of a Mac client. This means that sometime around the mid 2030's some poor programmers will have to take a break from worrying about Y0x80000000 to get bit by the x86-128 varargs bugs.
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…
That's the problem right there. 64 bits is not always 64 bits. While a 64 bit int gives you a 64 bit number (Actually a 63 bit number and a 1 bit sign flag). An IEEE double precision float only gives you a 52 bit number, and a separate 11 bit number as an exponent. So the problem is that declaring that 64 bits is 64 bits is actually precisely the issue here.
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…
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…
> 64 bits is 64 bits he said, right... well yes That's the problem right there. 64 bits is not always 64 bits. While a 64 bit int gives you a 64 bit number (Actually a 63 bit number and a 1 bit sign flag). An IEEE double precision float only gives you a 52 bit number, and a separate 11 bit number as an exponent. So the problem is that declaring that 64 bits is 64 bits is actually precisely the issue here.
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 range for positive numbers.
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…
Earlier quoted context omitted.
Heh. Sometime around '94 I helped Southwestern Bell Telephone with that during the 16 bit to 32 bit transitions of a Mac client. This means that sometime around the mid 2030's some poor programmers will have to take a break from worrying about Y0x80000000 to get bit by the x86-128 varargs bugs.
I'm not sure what you mean by the 16-to-32 transition on the Mac. Are you referring to the 68k-to-PowerPC transition?
Earlier quoted context omitted.
> 64 bits is 64 bits he said, right... well yes That's the problem right there. 64 bits is not always 64 bits. While a 64 bit int gives you a 64 bit number (Actually a 63 bit number and a 1 bit sign flag). An IEEE double precision float only gives you a 52 bit number, and a separate 11 bit number as an exponent. So the problem is that declaring that 64 bits is 64 bits is actually precisely the issue here.
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…