[coyotos-dev] [PATCH included] Test infrastructure for bignum

[Jonathan S. Shapiro]

On Fri, 2008-05-16 at 22:46 +0200, Thomas Stratmann wrote:
> > One small issue. The correct processing for "all other cases" is to
> > immediately terminate the attempt to look for further digits. So if we
> > are going to adopt your logic (which is conceptually fine), then the
> > last bit needs to be
> > 
> >    if (c != '0') break;  // end of digits in input string.
> > 
> > Do you agree?
> It is a matter of convention, or API promise.

Yes. In my opinion there are only two correct choices:

1. Raise an exception because input is malformed.
2. Behave like strtol and stop at first non-digit.

The current code does neither, which is a clear bug.

The second is convenient for parser-like processing, which is why I
(very slightly) prefer it.

> When constructing a BigNum from a string, I would say that it is an 
> error if the string does not properly represent a bignum in the first 
> place (the reason I am making this claim is that there is no way to 
> return the actual valid read length, or equivalent). Am I guessing right 
> that you would not like raising an exception here?

Hmm. You are raising a very good point about the read length here. This
may be a use-case for another constructor variant.

Yes, there is something very ugly about C++ exceptions, so I had hoped
to avoid them.

> A different case IMHO is reading from an istream (this case needs to be 
> discussed as well, as mentioned earlier). Here we want to be tokenizer 
> friendly. Being called from a tokenizer means "here (in the stream) 
> begins a bignum. parse it and return when done", and "done" can be 
> interpreted to happen at eof or at the first non-digit character.

Yes.

> The latter case should be looked at by someone who regularly builds 
> parsers and such...

Sure, but I don't happen to know anybody like that. :-)

> Corner cases that must be clarified as well:
> * when called with a base, ignore leading zeroes?
> * when called without a base, the first leading zero indicates octal 
> base, further ones are to be ignored?

My opinion:

If a base is supplied explicitly, it should be honored. Deducing the
base from the leading 0 (or 0[Xx]) is a fall-back kludge.

If the base is supplied explicitly, then there is no need to do anything
special to ignore leading zeros, because the "mulitply by radix and add
next digit" step automatically does the right thing.


shap