22.07.2014 14:44, Dimitry Sibiryakov wrote: > Instead of fixing "handling 32 bits internally without any bounds checking"
In general, I don't like platform dependent datatypes in the public API, hence my objections to size_t. (*) The problems, as I see them, are: 1) It may complicate client programs if their compiler misses a 100% analogue. One might need to introduce conditional compilation etc. 2) If the underlying implementation cannot deal with 64-bits-long objects, it (1) requires bounds checking and (2) partially defeats the whole purpose of interface as a contract (i.e. interface promises something it cannot handle). 3) If the underlying implementation can deal with 64-bits-long objects, the situation starts looking better. However, this is commonly *not* the case for Firebird (maybe Trace API is an exception here, I don't know). (*) I was objecting to using plain ints there for the same reason. We're just lucky to not supporting Itanium or some other platform with 64-bit ints. One day this issue will strike back but lots of wrongly defined headers will already be distributed around the world. Dmitry ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel