int versus ssize_t usage

[Randy Selzler]

Paul

bstrlib uses int instead of ssize_t in various places.
Is this a historical artifact or design decision with a rationale?
Would you be receptive to a new configuration option for ssize_t support?

At work we use big machines, where the real memory is as much as 1.5 TB (yes, 1.5 terabytes of real memory, not virtual). Note: int is 4 bytes but ssize_t is 8 bytes as needed for these big machines.

Thanks
Randy

[Paul Hsieh]

Ooops!  Missed this message somehow.

Anyhow, ssize_t is not a standard defined type.  I.e., its not defined for Microsoft, Watcom or Borland C or C++ as far as I know.  I wanted to use a type for ->slen which would not increase the number of compiler warnings from truncations and which was signed.  Furthermore, its rare to need a string > 32767 in length, so it seemed like an acceptable decision.

If you truly have strings > (1<<31)-1 in length, then your concern is not fast indexed access to each character (which is really what bstrlib gives you) but rather with how you abstract the storage of such strings.  In which case, I think a bsStream is usually a better abstraction.

If you can truly make the case, perhaps I can change the size to something like blengthscalar_t which would be typedefed at the beginning of bstrlib.h and could be set to ssize_t or int or any other large enough signed scalar.

Paul