RFC: Upgrade filter integer size to 64-bit

[Maria Matejka]

Dear fellow users of BIRD,

I'd like to do a quick survey. BIRD now uses a 32-bit unsigned integer 
inside filters. OTOH, most of the integer route attributes are stored as 
uintptr_t, which is 32-bit or 64-bit depending on architecture.

There are three basic options for further development:

1. Keep it as it is (32-bit filter integer, arch-dependent attribute 
integer).
   Pros:
   * Lesser memory footprint of route attributes on 32-bit archs
   Cons:
   * 8-byte attributes (currently only Babel RouterID) stored indirectly 
at least on 32-bit archs
   * Explicit checks and transformations between filters and attributes

2. Update both to 64 bits.
   Pros:
   * Much more convenient development
   Cons:
   * More memory eaten on 32-bit archs (actual ratio depends on how many 
route attributes you need to store)
   * Slower computation of arithmetics in filters on 32-bit archs

3. Make it completely arch-dependent, either both 64-bit or both 32-bit.
   Pros:
   * Uses both 32-bit and 64-bit archs in their intended way
   Cons:
   * Different behavior of filters on different archs
   * Possibly hard-to-discover architecture-dependent bugs

If it was on me, I'd choose to update everything to 64 bits and just 
hope that the 32-bit use cases aren't affected too much. I suppose that 
nobody is running BIRD at a low memory 32-bit box having lots of routes 
in kernel with Linux kernel route metrics set, which is the worst case 
scenario I can think about.

Is there anybody who would try to convince me that I shouldn't make 
filter integers and route attribute integers both 64 bits wide?

Thank you all for your answers.
Maria