[Botan-devel] RFC: changing type of length arguments
joel at joelsplace.sg
Fri Mar 14 20:02:10 EDT 2008
> -----Original Message-----
> From: botan-devel-bounces at randombit.net [mailto:botan-devel-
> bounces at randombit.net] On Behalf Of Jack Lloyd
> Sent: Saturday, 15 March, 2008 2:04 AM
> To: Botan Devel List
> Subject: [Botan-devel] RFC: changing type of length arguments
> Currently in Botan everywhere we represent a length, we use
> u32bit. For instance passing a byte/u32bit pair representing a byte
> array and its length is common in Botan.
> Question 1: Should Botan continue to use u32bit for this purpose, or
> something else?
> Question 2: If it should change, what to?
> Choices seemingly include:
> A new typedef, like Botan::size_type
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? :)
> Reasons I am thinking about this:
> - It can be hard to tell what is / is not intended as a length
> field. (We are not helping the type system help us). I am looking
> at the code and at this point feel like the best thing to do is
> ensure that bare u???bit typedefs are only used where it is the
> case that that variable must be that particular size for
> correctness. Length fields are a bit portion of the "other"
Agreed. U32bit is vague, and I'm sure 64-bit CPUs will not be fully utilized
when we use 32-bit unsigned ints for sizes.
> - It introduces limits that need not exist (4 gigs is enough for
> - Very hard to update / change the length in any easy way (this
> argues especially for a new size_type since, in theory at least, it
> would allow easy switching).
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?
> On the downside, I can imagine some subtle bugs resulting, especially
> given C++'s willingness to silently convert one integer type into
That's true. But I believe for most part replacing all u32bit's with
size_t's should be fine?
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?
More information about the botan-devel