On Sun, Aug 4, 2013 at 11:41 PM, Richard Smith <[email protected]>wrote:
> On Sun, Aug 4, 2013 at 9:58 PM, David Majnemer > <[email protected]>wrote: > >> ================ >> Comment at: lib/AST/MicrosoftMangle.cpp:894 >> @@ +893,3 @@ >> + case TemplateArgument::NullPtr: { >> + mangleIntegerLiteral(llvm::APSInt(/*BitWidth=*/64), >> /*IsBoolean=*/false); >> + break; >> ---------------- >> Richard Smith wrote: >> > Sending nullptr_t through the integer literal codepath seems >> unnecessary. All we really know here is that nullptr_t appears to be >> mangled as A@, so maybe just emit that directly. >> While we could do that, I think it makes the mangling scheme a bit more >> complicated semantically and it decentralizes the mechanism of choosing how >> to mangle zero-ish things. >> >> As an example: bool template arguments. True and false aren't given >> special mangling behavior. We "boolify" the integral value, treat the >> result as an integer and mangle **that** value. > > > That makes sense for bool, because it's an integer type, but there's > nothing really integery about nullptr. Plus the "64" here is > eyebrow-raising and ultimately irrelevant. (For Itanium, a null pointer > also happens to be mangled exactly as if it were an integer literal with > value 0 of the pointer type, but we have code to directly emit the mangling > there too.) > I find the argument behind nullptr's non-integralness sufficient to change direction, I've updated D1284. Thanks
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
