5 ms·
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, a
by mpyne 14y ago
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 int 0. That is, 32-bit int 0, whereas the function was expecting a 64-bit null pointer. So on 32-bit mode it happened to work fine, but crashed when compiled for 64-bit platforms.
- jws 14y agoHeh. 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.
- DerekL 14y agoI'm not sure what you mean by the 16-to-32 transition on the Mac. Are you referring to the 68k-to-PowerPC transition?
- derleth 14y agoInitially, I thought it was the transition to 32-bit-clean code in the 68k line, but that was more of a 24-to-32 transition, and it only affected pointers: http://lowendmac.com/trouble/32bit.shtml http://lowendmac.com/trouble/32bit.shtml
- yew 14y agoHuh. 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.
- CamperBob2 14y agoI'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 than the disease.
- to3m 14y agoBut 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.
- CamperBob2 14y agoRight, 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.
- vinkelhake 14y agoC++ doesn't have an automatic conversion from void* to T* so having NULL as ((void*)0) wouldn't have worked.
- CamperBob2 14y agoTrue, 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.
- bitwize 14y agoAnd this is why you use nullptr, not NULL.
- mpyne 14y agoYes, this is a great reason to have nullptr, but when this occurred there wasn't even such a thing as -std=c++0x. ;)