Mike Breuer wrote: > > 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). I would recommend that if you're already hitting this limitation you either just leave it as-is, run a conversion, or you test the first character, if it is '-' then you use atol() otherwise you use strtoul(). > 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. You can use strtol() instead since it has defined behavior in an out-of-range situation: If the equivalent value is too large to represent as type long, strtol stores the value of ERANGE in errno and returns either LONG_MAX, if x is positive, or LONG_MIN, if x is negative. > I > don't know of an unsigned equivalent to atol. atol(s) becomes strtoul(s, NULL, 10) I'm not sure of this so someone correct me if I'm wrong, but I think that it would be undefined to do something like use strtoll() (on a C99 compiler) and cast the result to an unsigned long if the result is out of range for an unsigned long so you should probably avoid that solution. Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST