API docs don't make the maximum value number clear

[James Aylett]

Unless you know what unsigned does on your platform (and it should really be platform independent), it's unclear. Should be clarified, and possibly the typedef fettled.

[Richard Boulton]

Some discussion on IRC with Olly just now. Summary I think is:

• C9X inttypes.h still isn't safe to rely on being available, we think.

• workarounds for that will probably involve generating header files from configure, which will get messy (and need further custom work for windows).

• instead, it's probably better to add a compile-time assert that unsigned has 32-bit unsigned range (which it will on all platforms we currently care about), and to document that a 32-bit unsigned range can be relied on for valueno.

The only other risk I can see associated with valueno being a variably sized value is if users serialise BAD_VALUENO on one platform (say, to a decimal representation), and then unserialise it on another with a larger/smaller unsigned size, they may get a valid valueno in return. Not sure if this is likely, or to be an issue, but its probably something else we should document too.

[Olly Betts]

BAD_VALUENO is probably serialised by the remote backend, so that is an issue we should definitely check out. A simple fix might be just to serialise slot + 1 (so BAD_VALUENO wraps to 0) and then subtract one at the other end.

[Olly Betts]

I've documented the range explicitly in the doc comment for the valueno type for trunk in r16156 and for 1.2 in r16158.

I also changed the static<valueno>(-1) to 0xffffffff for trunk in r16157 - it seems to me this is better as it's more robust to changes in the type width. If we really want to change the width globally, we can do that when we break ABI (and remote protocol and serialisation compatibility) since BAD_VALUENO means we are source compatible.