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

Joel Low joel at joelsplace.sg
Fri Mar 14 20:02:10 EDT 2008


Hello,

> -----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?
> 
No.

> Question 2: If it should change, what to?
>  Choices seemingly include:
>    A new typedef, like Botan::size_type
>    std::size_t
>    u64bit
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"
>    category.
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
> anyone?)
As above.

> 
>  - 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
> another.
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?

Regards,
Joel





More information about the botan-devel mailing list