Re: [CODE] More fun!

From: Mike Breuer (
Date: 06/04/01

From: "Daniel A. Koepke" <dkoepke@CIRCLEMUD.ORG>
> Better yet change all bitvectors to be unsigned.  There's no reason to
> encounter the problem with the sign bit at all and there's no reason to
> make the loading code handle such a case.  All bitvectors should be
> unsigned.  Don't be worried about breaking binary compatability: the
> binary representation does not change.
> It should be noted, however, that they don't appear to be in the stock
> code.  I should change this.

The binary representation doesn't change, but the values in the mob file do
(for example).  In the previous example, -2145386488 becomes 2149580808 as an
unsigned number.  This causes two problems:

1. negative numbers in the mob file would have to be converted to their
unsigned equivalent, or the files will break (not a problem in the stock code,
but a problem for people already hitting this limitation).

2. Since numbers like 2149580808 are out of range for a signed long, the
behavior of atol (called when parsing values out of the file) is undefined.  I
don't know of an unsigned equivalent to atol.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/05/01 PST