libsmbclient for Samba4: initial design issues

[Jelmer Vernooij]

Hi Tridge, Derrell,

On Sat, 2005-08-13 at 11:58 +1000, tridge at samba.org wrote:
> 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.

We already have this (and use it), though it's currently called _PUBLIC_
rather than PUBLIC. That macro allows us to (on most common platforms),
have a shared library only export the symbols marked _PUBLIC_ and hide
the other ones so that they don't pollute the namespace. 

This relies on the 'visibility' attribute in gcc. 

I agree that prefixing function names is not the right way to do
namespacing. 

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20061101/6bc8c600/attachment.bin