libsmbclient for Samba4: initial design issues

[tridge at samba.org]

Derrell,

yes, I understand what you're trying to achieve, you want all symbols
in any Samba supplied libs to hide behind a single part of the
namespace. My objection is that it adds another level of prefix to
every single function, which I think makes the code less readable.

Perhaps we could look at a different technical solution? I believe
that gcc and the GNU binutils has a way of marking functions as being
public when the code is in a library, thus allowing C code to specify
a 3 level scoping of "public", "internal" and "file", instead of the
usual 2 level scoping of "public" and "file" given by
static/non-static.

This wouldn't help us on non-GNU platforms, but it would solve the
namespace problem on the majority of our users platforms, and the
other platforms can just live with the (very small!) chance of a name
collision with the small range of prefixes we have now.

To do this we'd need something like:

#ifdef __GNUC__
# define PUBLIC __attribute__(_some_magic_attribute_)
#else
# define PUBLIC
#endif

then you would add PUBLIC in front of the functions you want to expose
in libsmbclient.

It might be that __GNUC__ is the wrong test, as perhaps some other
compilers have this capability as well, in which case a autoconf test
would be appropriate.

I also think that reducing the number of namespace prefixes we use is
worthwhile, so your example of BlockSignals() is a good one, and that
should indeed change, perhaps to sys_block_signals(), but I don't
think the namespace problem is big enough to burden every internal
function with a smb_ prefix.

Cheers, Tridge