On Tue, 5 Apr 2005, Bob Johannessen wrote:
> 1) Is there an official Exim coding standard documented somewhere? If
> so, where do I find it? If not, what is the de-facto policy on coding
> standards for patches?
There ought to be, now that we have more people working on the code.
When I have an idle moment I'll try to write something brief. Up to now,
I've just applied my own coding rules, some of which are:
. No TABS.
. Layout, spacing, etc. as you see it in most of the source (my "standard"
dates from 1968, before C was invented :-)
. Use unsigned char (uschar) as much as possible.
. Always test non-Boolean variables explicitly, e.g. if we have
int x;
uschar *p;
then always write if (x != 0) and if (p != NULL) and not just
if (x) or if (p).
. Each function gets a distinctive header comment and a listing of its
arguments and result.
. Comments on anything at all tricky.
. On the whole, a global function called xxx_something will be found in
the source file xxx.c (this is not universally true).
. Use casts to avoid compiler warnings (I test with -Wall on gcc).
There's probably more that I can't think of offhand.
> 2) Expansion variables: What is the proper way of flagging that an
> expansion variable is unset? Setting its pointer to NULL? Setting its
> pointer to point to an empty string? Is there a difference? I ask
> because it takes less code to just point the unset variables to
> empty strings.
For string expansion variables, calling the expander function with NULL
or an empty string will give the same result. It is possible that some
variables are treated differently internally, but I can't think of any
examples. For non-string variables, there isn't really an "unset" value.
> 3) In code that runs from the DATA ACL, is it safe to assume that the
> (global) variables sender_host_address, sender_helo_name and
> sender_address are never NULL?
I don't think it is safe. For local (-bs) SMTP, $sender_host_address
expands as an empty string; I think it may well be NULL internally. Same
for the others.
> 4) If socket(2) returns > -1, you must call close(2) on the result to
> avoid leaking file descriptors. True?
I would guess so.
> 5) snprintf(3) will always \0 terminate it's first argument, even if
> it has to truncate it to make room for the \0. True?
I have never used snprintf because it isn't part of the C standard, and
so I didn't know (back in 1995) which systems were likely to have it. It
may now be the case they all do, but I don't actually know. As it is not
standardized, it is also hard to check the answer to your question on
every OS that Exim runs on.
Instead of snprintf, I wrote my own function string_vformat(), which
does a similar thing.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
