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
pgpH3vfidXdO4.pgp
Description: PGP signature
_______________________________________________ Help-libidn mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-libidn
