Nikos Mavrogiannopoulos <[email protected]> writes:

> It has but the detection is done through major and minor lib version.
> Are they updated?

Not yet. I could add a version number bump on that branch, and see if
the tests then pass. I generally recommend configure checks for features
used rather than version checks, whenever practical.

> (btw. I'd really recommend providing easy to use
> macros for version detection)

I know... As I see it, that could be motivated by convenience primarily
for projects not using autoconf.

> However what is the goal with this rename?

To be able to change the size in later releases, without *subtle*
breakages of applications using the old and documented api.

> Wouldn't it make sense to remove them from the map file as
> well, and only export symbols starting with nettle_*?

I'm considing it, but it's not trivial. A related option is to move
declarations into internal, uninstalled headers.

First, symbols have underscores for a few different reasons; the symbols
I'm renaming here have it only because size is private and it may leak
into the abi with some flavors of linking. Otherwise, they're well
documented and unlikely to see any incompatible changes.

Other symbols, e.g., _nettle_sha256_compress and _nettle_umac_nh, are
internal interfaces which might change if nettle gets new or different
optimizations.

And there are different kinds of possible uses:

0. From within the nettle library.

1. From test and benchmarking executables in Nettle.

2. From user's experimental code, which don't care much about api or abi
   compatibilities with other versions.

3. Statically linked binaries, e.g, on embedded systems, might access
   _nettle_secp_256r1 directly to avoid an extra level of indirection
   and runtime lookup, with no real problem.

4. Plain applications relying on both api and abi stability.

We need to allow (1) (at least for some of the _nettle_* symbols).
We need to strongly discourage (4). For (2) and (3), it would be nice to
be liberal, but it might be fine to simply export more symbols in the
static library.

Removing declarations from internal header files would allow (1) and
(2), and strongly discourage all other use (if anyone adds their own
declarations to be able to call internal functions in a library they are
using, they ought to understand they're in unsupported territory).

What would it take to hide all _nettle symbols in libnettle.se? Just
delete the _nettle_* line in libnettle.map.in, like

--- a/libnettle.map.in
+++ b/libnettle.map.in
@@ -9,7 +9,6 @@ NETTLE_@LIBNETTLE_MAJOR@
 {
   global:
     nettle_*;
-    _nettle_*;
 
   local:
     *;

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to