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

Reply via email to