data type size_t supersedes int for Len information...

[Thomas-Haase]

...because the affected functions are e.g. passing sizeof based values, which does not work in 64-Bit build, because 64 bit size does not fit into int.

[david-maw]

Interesting problem, the limit on an SSL/TLS message is 16384 bytes, so obviously less than an int can hold. So there's some argument for using a short, but a size_t parameter might be easier for 64 bit callers. The downside of size_t is that it means the method signature changes between a 32 and 64 bit build, on the other hand DLL's normally run in the caller's process (weird COM situations notwithstanding), so the changing signature might be an advantage, not a problem. I'm interested in your opinion.

[Thomas-Haase]

• I do not like signed data types for Len, because caller can pass negative values
• Note, for the Len parameter you are using ULONG in StreamClient\ISocketStream.h and int in T:\temp\github\StreamSSL\StreamServer\ISocketStream.h. This is confusing and inconsistent. Is there a reason to have this file twice with different content?
• I would prefer size_t, because 64 Bit should be the main focus

[david-maw]

Annoyingly winsock has a nasty habit of using negative lengths as a flag that something went wrong, but that's just history, nothing to stop us improving on it. the ULONG versus int thing is just an oversight, not a subtle requirement I agree size_t is probably a better idea - I'm a bit paranoid about ABIs that change between 32 and 64 bit since I cut my teeth on COM and a "bitness dependent" IDL was rarely a good thing. That said, this is a source level interface, guaranteed to be in-process, so size_t has advantages that I'm good with.