On Thu, Jun 28, 2012 at 6:30 PM, Cory Nelson <[email protected]> wrote:
> Probably not an issue -- I'm not sure how a public API would need inttypes > anyway. Also, perhaps you are seeing size_t be misused. A blanket "please > don't use" is nonsense. > Hi, Cory! That's what i thought to until i started porting my i/o-centric APIs to 64-bits. size_t has at least the following drawbacks compared to using a fixed-size integer type: - No standard size, so it is not terribly useful in platform-independent file formats. - There are no standard printf()/scanf() specifiers for it, which means those funcs cannot be used with size_t or ifdefs or casts are needed to handle them portably. All of the fixed-size integer types have portable scanf/printf specifiers except that int8_t and scanf has a caveat due to the compiler upgrading a (int8_t*) to a wider pointer (at least on gcc, where it warns if you try to pass (int8_t*) to sscanf and friends). - Structs which contain size_t members cannot have guaranteed sizes, so they cannot be portably serialized without writing routines to do the numeric conversion and check the value's range on the target platform. This adds complication to any sort of deserialization involving size_t. The way i "solve" this in my libraries is to have a config option for however many bits the lib supports, e.g. 16-64, and then define a lib-specific type, my_lib_size_t, aliasing the appropriate fixed-size type. This is essentially what sqlite does with sqlite3_int64 and friends, though i don't know if sqlite guarantees _minimum_ or _absolute_ integer lengths. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
