64-bit bugs in new ovdb

[Heath Kehoe]

>
>A network long is 32 bits, so it's going to break for article numbers
>larger than 32 bits--probably by losing the high bits (in fact, htonl
>and ntohl were my first suspects, but I eventually convinced myself
>that they weren't causing trouble, yet).  Other things probably will
>break as well--for example,
>
>void *OVopensearch(char *group, int low, int high);
>
>probably ought to be
>
>void *OVopensearch(char *group, ARTNUM low, ARTNUM high);
>
>It seemed like an academic issue--my active file will need to be
>regenerated long before then--so I didn't worry about it (despite
>being an academic...).

Besides, the NNTP specs dictate that the maximum allowed article
number is 2^32-1.  I was thinking maybe we could make ARTNUM
a u_int32; but that would break existing INN installations on 64-bit
systems (where structs stored in files have ARTNUM-sized members).

>
>>If not, I'll have to change the artnum's so that they are u_int32_t.
>>If there are two 32-bit ints, there won't be padding between them,
>>right? (on a 64-bit system, I mean).
>
>There won't on the alpha, and I'd expect that to be true on most other
>64-bit systems, but there's nothing that guarantees that--the compiler
>is allowed to insert padding anywhere except the beginning of a
>struct.  When you're passing a struct that is going to be treated as a
>chunk of memory by the callee, you generally have to zero it first if
>you want to be safe.  The alternative is to pack it yourself into a
>array of char, which is a pain, but is the only choice if the
>resulting database needs to be portable across architectures.
>

The requirement isn't portability; the requirement is sorting.  The
keys are memcmp()'ed, which treats the struct as a hunk of binary
data; and the keys must be sorted in article order.  Hence, they
must be stored big-endian.

I will apply your patch that adds the memset()s, and double-check
the code for other related gotcha's.

But to fix the problem of using htonl() on 64-bit ints (even though
it works for you, it may not work on other 64-bit OSs), I'll have
to either change the artnum member of struct datakey to 32-bits,
or implement a 64-bit version of htonl().

-heath