cURL / Mailing Lists / curl-library / Single Mail


RE: [PATCH] smb/cifs

From: Nagel, Bill <>
Date: Mon, 10 Nov 2014 19:17:52 +0000

> Is there any chance you could get documentation patches to us sooner
> rather than later as this will help me (and possibly others) understand your
> implementation a little more and test it without any test cases?

Once the patches are merged, I will submit another set for docs and tests.

> 2) More importantly:
> * Do we need to support / and \ as separators for the domain in the
> username? I appreciate we currently do this elsewhere in curl but my
> understanding is that the correct format of down-level usernames is
> DOMAIN\user where DOMAIN can be either the flat or full NetBIOS domain
> name. I also believe we opened discussion earlier this year about removing
> the / support as I believe this is a curlism and not industry standard -
> however - if you know of a reason to support both please free to correct me
> ;-)

I believe smbclient allows forward slashes, which is why I supported it, but I don't mind only supporting backslash.

> * The SMB code isn't conditionally compiled out with the appropriate
> CURL_DISABLE_SMB protection except in url.c and version.c - the source
> code needs it as well just like http.[c|h], smtp.[c|h], pop3.[c|h], etc... do


> * Do we need to make the SMB code dependent on USE_NTLM as well? - so
> when performing #ifndef CURL_DISABLE_SMB use #if defined(USE_NTLM)
> && !defined(CURL_DISABLE_SMB) instead - see point 5 below.

I think I will alter the #define in curl_ntlm_core.c like you suggested.

> * I don’t think we should be typedefing stdint types in smb_data.h
> depending on whether we HAVE_STDINT_H and HAVE_LONGLONG. If we
> are going to take this approach then they should be defined properly in
> either curl_setup.h or the config header files, however, I'd rather see us use
> the more common non stdint compliant types used in the SMB code as we
> are supposed to be C89 compliant. However, we may want to open up
> discussion a little more rather than just input from myself.

I would prefer to use types that are explicit about their size since this is a binary protocol, whether they are stdint types or something else.

> 3) When I came to build (Windows x64 with OpenSSL) I received the
> following builds warnings:
> smb.c(229): warning C4018: '<' : signed/unsigned mismatch
> smb.c(261): warning C4244: 'function' : conversion from 'unsigned
> __int64' to 'u_short', possible loss of data
> smb.c(268): warning C4013: 'getpid' undefined; assuming extern
> returning int
> smb.c(370): warning C4244: '=' : conversion from '__int64' to 'uint16_t',
> possible loss of data
> smb.c(396): warning C4244: '=' : conversion from '__int64' to 'uint16_t',
> possible loss of data
> smb.c(412): warning C4267: '=' : conversion from 'size_t' to 'uint16_t',
> possible loss of data
> smb.c(457): warning C4244: '=' : conversion from 'curl_off_t' to 'uint32_t',
> possible loss of data
> smb.c(484): warning C4244: '=' : conversion from 'curl_off_t' to 'uint32_t',
> possible loss of data
> If the conversions between different sized integers is intentional then please
> uses the functions in warnless.h to explicitly convert them and trap a large
> value.


> 5) If I build without NTLM support (either a) without an SSL/crypto library, b)
> without Windows SSPI or c) I define CURL_DISABLE_CRYPTO_AUTH) then I
> also received the same unresolved external function warnings.

I believe a #error in curl_ntlm_core.c will catch this.



This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

List admin:
Received on 2014-11-10