libsmbclient - Thread Saftey

[Derrell Lipman]

On Mon, Oct 6, 2008 at 10:19 AM, David Collier-Brown <davecb at sun.com> wrote:

> Derrell Lipman wrote:
>
>> Yes, all of those libsmb-* files are libsmbclient.
>>
>
> Ok, then there are only a few issues left in the whole directory:


Great, thanks!


>
> froggy> cat libsmbclient.report
> atof - convert string to double-precision number
>    MT-Level: MT-Safe as  long  as setlocale(3C) is not
>    called to change the locale.
>

How in the world can atof() be non-thread-safe?  Why would locale have
anything to do with it?  It returns a double and I can't think of any reason
why it would need to use any non-thread-safe features...???  Is strtod()
deemed to be more thread safe?


>
> ctime - convert date and time to string
>    MT-Level: MT-Safe with exceptions
>    the ctime(), gmtime(), and localtime()  functions
>    are  safe  to  use  in multithread applications because they
>    employ  thread-specific  data.   However,   their   use   is
>    discouraged  because  standards  do  not  require them to be
>    thread-safe. Use  asctime_r(), gmtime_r() and ctime_r(),
>

Yes, this is a real issue if the implementation does not use thread-specific
data.  The problem is that the _r functions are not standardized either
(even their existence) so using them doesn't really help.  I suppose one
could add ctime_r to libreplace...  Do we have any idea what, if any,
implementations of ctime() do not use thread-specific data?

getpass - read a string of characters without echo
>    MT-Level: MT-Unsafe
>
> Found in:
> "./clidfs.c",
>      209:
>

I think there's a more serious issue here.  getpass() is only called if no
password has been provided and kerberos is not in use.  Those things are
determined, however, via members of a static structure in cli_dfs.c
(cm_creds) which is clearly not appropriate for different threads providing
different credentials.  This is the kind of samba core issue (not
libsmbclient-specific code) I was talking about, that I think Jeremy
indicated that he hopes to be working on.

Thanks again,

Derrell