[Botan-devel] RFC: changing type of length arguments
Jack Lloyd
lloyd at randombit.net
Fri Mar 14 14:04:16 EDT 2008
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
std::size_t
u64bit
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.
- It introduces limits that need not exist (4 gigs is enough for anyone?)
- 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).
On the downside, I can imagine some subtle bugs resulting, especially
given C++'s willingness to silently convert one integer type into
another.
-Jack
More information about the botan-devel
mailing list