7. Hacking Taylor UUCP

This chapter provides the briefest of guides to the Taylor UUCP source code itself.

7.1 System Dependence
7.2 Naming Conventions
7.3 Patches

7.1 System Dependence

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 file `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 has been used on a 16 bit segmented system with no function prototypes, so I'm fairly certain that all casts to long and pointers are done when necessary.

7.2 Naming Conventions

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'

array; the next character is the type of an element

`b'

byte or character

`c'

count of something

`e'

stdio FILE *

`f'

boolean

`i'

generic integer

`l'

double

`o'

file descriptor (as returned by open, creat, etc.)

`p'

generic pointer

`q'

pointer to structure

`s'

structure

`u'

void (function return values only)

`z'

character string

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'.

7.3 Patches

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.