I'm breaking this out from LLVM asserts thread. Here are all the assertions in APInt I consider should be recoverable: APInt::APInt: bitwidth too small Null pointer detected! APInt::getBitsNeeded: Invalid string length string is only a minus! Invalid radix APInt::fromString: Radix should be 2, 8, 10, or 16! Invalid string length string is only a minus Insufficient bit width Invalid digit in string for given radix APInt::toString: "Radix should be 2, 8, 10, or 16! For the recoverable APFloat assertions: assertArithmeticOK: Compile-time arithmetic does not support these semantics readExponent: Exponent has no digits Invalid character in exponent totalExponent: Invalid character in exponent skipLeadingZeroesAndAnyDot: String cannot be just a dot interpretDecimal: Multiple dots in float Invalid character in digit string trailingHexadecimalFraction: Invalid trailing hexadecimal fraction! I'd expect we'd want to keep the assertions that check to make sure we're comparing APInts and APFloats of the right semantics. I'm not sure if it makes sense trying to change this right before the code freeze, especially since I can't find any other classes that have similar semantics that we could copy. So, what should we do?
On Aug 19, 2009, at 9:36 PM, Erick Tryzelaar wrote:> I'm breaking this out from LLVM asserts thread. Here are all the > assertions in APInt I consider should be recoverable: > > APInt::APInt: > bitwidth too small > Null pointer detected!Hi Eric, As we discussed on IRC, I don't think there is any reason for the implementation of these methods to check these invariants. These are clear API invariants that the caller can check if needbe. Making the implementation check these will slow down clients which are known to be well formed. I didn't look at all of the things you listed, perhaps some other ones would make some more to be recoverable errors. -Chris> > APInt::getBitsNeeded: > Invalid string length > string is only a minus! > Invalid radix > > APInt::fromString: > Radix should be 2, 8, 10, or 16! > Invalid string length > string is only a minus > Insufficient bit width > Invalid digit in string for given radix > > APInt::toString: > "Radix should be 2, 8, 10, or 16! > > > For the recoverable APFloat assertions: > > assertArithmeticOK: > Compile-time arithmetic does not support these semantics > > readExponent: > Exponent has no digits > Invalid character in exponent > > totalExponent: > Invalid character in exponent > > skipLeadingZeroesAndAnyDot: > String cannot be just a dot > > interpretDecimal: > Multiple dots in float > Invalid character in digit string > > trailingHexadecimalFraction: > Invalid trailing hexadecimal fraction! > > > I'd expect we'd want to keep the assertions that check to make sure > we're comparing APInts and APFloats of the right semantics. > > I'm not sure if it makes sense trying to change this right before the > code freeze, especially since I can't find any other classes that have > similar semantics that we could copy. So, what should we do? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, Aug 19, 2009 at 11:08 PM, Chris Lattner<clattner at apple.com> wrote:> > As we discussed on IRC, I don't think there is any reason for the > implementation of these methods to check these invariants. These are clear > API invariants that the caller can check if needbe. Making the > implementation check these will slow down clients which are known to be well > formed. I didn't look at all of the things you listed, perhaps some other > ones would make some more to be recoverable errors.By that logic, I think it's safe to say then to say that it's an invariant of APInt and APFloat to pass in a well formed string, and that it's the client's responsibility to make sure that the string isn't invalid. Which then follows that the assertions checking the validity of the string should stay. I'm happy with that decision if you are.