Steve Parkinson wrote:
I've been playing with SWIG a little. It seems too easy!
My comments so far:
1) Private function definitions. SWIG can make wrapper functions for all
functions declared in the header files. But, not all of those end up
being exposed in the .so, (due to nss.def). You really need to
explicitly list the functions in your API that you want to expose, to
avoid run time linker problems.
I think it would be better if all functions not in nss.def are moved to
private header files, which are only #included if NSS_PRIVATE is
defined. This would also have the benefit of a) not confusing people
about the API, and b) helping the compiler catch errors, instead of the
linker.
Is this required to "SWIG" NSS for use in scripting languages? Or is it
just that it would be nice to have these private functions also exposed
to the scripting language?
2) CERT_AsciiToName returns a CERTName*. And, I passed this pointer into
another function with no problems at all. It even does run-time type
checking to make sure it's the right kind of pointer. I have a great
deal of confidence that the rest of the opaque typedefs that NSS uses
will work just as well.
I didn't even really look at typemaps yet, but I did notice there is
support in SWIG for things like out or inout parameters, and callbacks
too. Sounds promising
It's pretty easy to write typemaps for doing things like converting an
array of strings in the scripting language to a C char **, and vice
versa, and making sure the memory is cleaned up appropriately.
Callbacks are a little trickier - you need some sort of wrapper function
in order to pass in a scripting language sub or proc as a callback.
3) NSS is a fairly object-oriented API. But, it lacks a formal
definition of the objects, and how they interrelate. As such, it
is not possible to get swig to automate the creation of language
specific classes.
For example, many of the CERT_* calls just scream out to be attached
to an object.
<WEAR clothing="flame-retardent suit" language="C++" >
SWIG can parse C++ though. So, maybe what we can do is to write a C++
object oriented wrapper around the whole of NSS, and use that as a
basis for the API we want to expose.
Yes, and in fact SWIG can generate "object oriented wrappers" around
many C++ constructs.
</WEAR>
Heikki - I'm really not that concerned about performance. After all,
we're talking scripting languages here - I don't think performance is
the goal.
Steve
------- nss.i -------
%module nss
%{
#include "nss.h"
#include "cert.h"
%}
%include "nss.h"
extern CERTName *CERT_AsciiToName(char *string);
extern char *CERT_GetOrgUnitName(CERTName *name);
------- build.sh --------
#!/bin/sh
# I run this from the 'nss header file directory'
# this command will spit out a 'nss_wrap.c' and 'nss.pm' perl module
swig -importall -ignoremissing -perl5 nss.i
gcc -I ../../Linux2.6_x86_glibc_PTH_DBG.OBJ/include/ -c nss_wrap.c \
`perl -MExt Utils::Embed -e ccopts`
ld -G -o nss.so nss_wrap.o -l nss3
------- test --------
#!/usr/bin/perl
use nss;
nss::NSS_NoDB_Init(".");
$name = nss::CERT_AsciiToName("cn=steve,ou=engineering,o=Red hat");
$orgunit = nss::CERT_GetOrgUnitName($name);
print "orgunit = $orgunit\n";
------ test output --------
orgunit = engineering
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
