Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
Apparently on Windows the SAL_DLLPUBLIC_EXPORT does not work for unknown
reasons, so use the old mapfiles on that platform.
Should fix regressions from 1fb5eb21, 48dbaa51, a9da5a0b.
>>= operator overload turn the right-value of the operator into a
left value... which confuse the heck out of the compiler's detection
of use of unitialized variables (and also C-reader like me for
whom >>= means something else altogether...
(why on earth are we right-bitshifting... with an unitialized variable...
oh! fracking operator overload!!!)
After successful last(), isLast() should return true!
Thus, when moving to last record, keep that fact in mind (update m_bEOF) so that isLast returns right result.
Also update m_bEOF on other moves.
Update m_nRowPos on next(), for the same reasons, mutatis mutandi.
Else (on 64bits platform) the driver smashes our stack: SQL_ULEN is 64 bits
Widen result type of getQueryTimeOut, getMaxFieldSize and getMaxRows so that it will always fit
