This chapter provides the briefest of guides to the Taylor UUCP source code itself.
The code is carefully segregated into a system independent portion and a system dependent portion. The system dependent code is in the `unix' subdirectory, and also in the files `tcp.c', `tli.c' and `sysh.unx' (also known as `sysdep.h').
With the right configuration parameters, the system independent code
calls only ANSI C functions. Some of the less common ANSI C functions
are also provided in the `lib' directory. The replacement function
strtol in `lib/strtol.c' assumes that the characters A
to F and a to f appear in strictly sequential order.
The function igradecmp in `uuconf/grdcmp.c' assumes that the
upper and lower case letters appear in order. Both assumptions are true
for ASCII and EBCDIC, but neither is guaranteed by ANSI C. Disregarding
these caveats, I believe that the system independent portion of the code
is strictly conforming.
That's not too exciting, since all the work is done in the system dependent code. I think that this code can conform to POSIX 1003.1, given the right compilation parameters. I'm a bit less certain about this, though.
The code is in use on a 16 bit segmented system with no function prototypes, so I'm certain that all casts to long and pointers are done when necessary.
I use a modified Hungarian naming convention for my variables and functions. As with all naming conventions, the code is rather opaque if you are not familiar with it, but becomes clear and easy to use with time.
The first character indicates the type of the variable (or function return value). Sometimes additional characters are used. I use the following type prefixes:
A generic pointer ('p') is sometimes a void *, sometimes a
function pointer in which case the prefix is pf, and sometimes a pointer
to another type, in which case the next character is the type to which
it points (pf is overloaded).
An array of strings (char *[]) would be named az (array of
string). If this array were passed to a function, the function
parameter would be named paz (pointer to array of string).
Note that the variable name prefixes do not necessarily indicate the type of the variable. For example, a variable prefixed with i may be int, long or short. Similarly, a variable prefixed with b may be a char or an int; for example, the return value of getchar would be caught in an int variable prefixed with b.
For a non-local variable (extern or file static), the first character after the type prefix is capitalized.
Most static variables and functions use another letter after the type prefix to indicate which module they come from. This is to help distinguish different names in the debugger. For example, all static functions in `protg.c', the `g' protocol source code, use a module prefix of `g'. This isn't too useful, as a number of modules use a module prefix of `s'.
I am always grateful for any patches sent in. Much of the flexibility and portability of the code is due to other people. Please do not hesitate to send me any changes you have found necessary or useful.
When sending a patch, please send the output of the Unix diff
program invoked with the `-c' option (if you have the GNU version
of diff, use the `-p' option). Always invoke diff
with the original file first and the modified file second.
If your diff does not support `-c' (or you don't have
diff), send a complete copy of the modified file (if you have
just changed a single function, you can just send the new version of the
function). In particular, please do not send diff output without
the `-c' option, as it is useless.
If you have made a number of changes, it is very convenient for me if you send each change as a separate mail message. Sometimes I will think that one change is useful but another one is not. If they are in different messages it is much easier for me to apply one but not the other.
I rarely apply the patches directly. Instead I work my way through the hunks and apply each one separately. This ensures that the naming remains consistent, and that I understand all the code.
If you can not follow all these rules, then don't. But if you do, it makes it more likely that I will incorporate your changes. I am not paid for my UUCP work, and my available time is unfortunately very restricted. The package is important to me, and I do what I can, but I can not do all that I would like, much less all that everybody else would like.
Finally, please do not be offended if I do not reply to messages for some time, even a few weeks. I am often behind on my mail, and if I think your message deserves a considered reply I will often put it aside until I have time to deal with it.