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
