On Sat, 29 Nov 2014, Daniel Stenberg wrote:

> > At the minimum I need to typedef a 64-bit int.
>
> Right now the code seems to assume that we have long
> long _or_ an __int64 type.
>
> First, if that is really what you want I think you should have
> a local typedef or something to avoid a series of #ifdefs.

Bill's patches to me had typedef'd smb_u8, smb_u16, smb_u32 and smb_u64 and unfortunately the smb_u64 type would still not build on systems without 64-bit support.

I have asked him to start a discussion here to see what the best way forward - in the meantime, as I want to git SMB into the next release and not hold it up anymore, I would rather use native types until a solution that everyone is happy with is found.

I have suggested:

* We extend our support of curl_off_t with a curl_off_tu type - we can then test the size of CURL_SIZEOF_CURL_OFF_T and disable SMB if necessary
* We use uint8_t, uint16_t, etc... and typedef these on systems where they don't exist, just like we do with size_t and ssize_t, and then we can then make uint64_t a struct on systems that don't have it (as Bill has suggested to me)
* We introduce our own curl_ types similar to the C99 based types and define a struct as above

There may be other options as well which I haven't thought about.

> Then, libcurl still builds on systems without any 64bit type so if
> that support is mandatory for the SMB code to work, I guess
> there's some more preprocessor magic needed.

I think we (and I will need to double check this) have a breakage in the ntlm code with write64_le() which is similar as is left over from the NTLMv2 work from early this year. I have been meaning to check this out and disable NTLMv2 if that is the case but just haven't found the time yet :-/

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-11-30