Annotating libidn with Deputy

[Linus Nordberg]

Hi,

I'm trying to compile libidn with Deputy[0] (part of Ivy[1]) and have a
couple of questions for you.  But first I'd like to explain my intents
and how I think this should be done.  Comments are welcome.

The goal is to be able to compile libidn with the Deputy compiler if the
user configures --with-deputy and necessary stuff is found being
installed on the host used for compiling.  The resulting library
includes runtime checks inserted by the Deputy compiler and can be
linked into an ordinary C program without any special treatment.

The code base of libidn should be close enough to the original code for
ordinary C programmers to read, understand and maintain the code.  Any
runtime penalties, execution speed and memory footprint, should be
"small enough" for ordinary use of the library.


So far, about 70% of (non generated) source code in the lib subdirectory
has been successfully compiled with Deputy without breaking any of the
selftests (make check).  I have admittedly used the TRUSTED keyword in
quite a few places, resulting in less checking than possible.  This work
should be seen as a starting point for adding more proper annotations.


Now, questions.

1. Would it be ok to rewrite non public functions in a way that avoids
using the same formal parameter for denoting buffer lengths as both
input and output, i.e. replacing (size_t *len) with (size_t len_in,
size_t *len_out)?  The API will be a bit more clunky to use, but it's
only internal to libidn code.

2. . In the case of public functions with an interface not well suited
for Deputy, I'd like to rewrite them in a more Deputy friendly way,
rename them and write a wrapper using the original function signature.
I've suffixed the ordinary function name with `_df' so far.  Can you
think of better naming schemes?

3. There are a number of functions with parameters like (char *str,
ssize_t len) where len is the length of str unless len == -1 in which
case str is null terminated.  Most of these are found in nfkc.c,
f.ex. stringprep_utf8_to_ucs4().  Would it be ok to complement each of
these with two other functions, the first one taking (char *str, size_t
len) where len is length and the other function just taking (char *str)
where str is null terminated?  This is more in line with other parts of
the library, where we have functions suffixed with 'z' which are
wrappers taking null terminated strings.

4. Since the source code is annotated with Deputy-specific keywords, a
plain gcc build will need to have these keywords "removed".  This can be
done by including a file which #define's these as empty.  Since the
exported header files are annotated too, this file should probably be
included by each header file and must be put in a place where the
compiler can find them.  What would be the best way to do this?

5. Would it be ok to change libidn to use strncpy, strncat and friends?
Mostly for avoiding warnings from Deputy.

6. Most importantly, do you think that this is a good idea?  Would you
be interested in using libidn compiled with Deputy?


[0] http://deputy.cs.berkeley.edu/
[1] http://ivy.cs.berkeley.edu/

-- 
Linus

pgpXFI3LWIJRR.pgp
Description: PGP signature