[Botan-devel] RFC: changing type of length arguments

[Jack Lloyd]

> I believe std::size_t will be the best. Most of the STL container types use
> it, and since we are suing C++ chance are we'll be using the STL and all our
> sizes will be of the type std::size_t. Why not just follow it? :)

> I'm not sure about libc and libstdc++, but I believe under VC even on 32bit
> a few types are already 64bits long - and why would you require changing the
> size in the future?

I had been really thinking a typedef in the Botan namespace, but this
does make sense, and stddef.h is a pretty benign header to include
into build.h, since most other headers will need NULL and size_t
anyway.

> > On the downside, I can imagine some subtle bugs resulting, especially
> > given C++'s willingness to silently convert one integer type into
> > another.
> That's true. But I believe for most part replacing all u32bit's with
> size_t's should be fine?

I've thought about this a bit more, I think you are right that it is
unlikely to cause problems in practice.

> Furthermore, I'd also like to bring up the use of Botan::byte* for passing
> data in. I know that Botan::byte* will allow the full range of unsigned
> values 0-255 to be stored, but I don't really see parts of the standard
> streams library using unsigned char arrays for taking in/writing data and
> they all just use "char". Why is there a distinction in Botan?

Often we want to do unsigned arithmatic on those values, which would
mean we would in have to cast to unsigned char anyway (and
reinterpret_cast is ugly). The iostreams and such only treat char* as
a bag of bits so it doesn't care about how the math wraps.

-Jack