[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

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"

 - 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


More information about the botan-devel mailing list