Re: [Exim-dev] Bits and pieces

Góra strony
Delete this message
Reply to this message
Autor: Matthew Byng-Maddick
Data:  
Dla: exim-dev
Temat: Re: [Exim-dev] Bits and pieces
On Wed, Mar 10, 2004 at 04:46:49PM +0100, Phil Pennock wrote:
> As regards the C standard coding ... the contrasting examples of
> operator comparison have inverted meanings. "if (!p)" is probably meant
> for some. And the reason for using "*p = '\0'" is that some less common
> architectures don't necessarily use the same bit-pattern to represent a
> null pointer and the ASCII NUL character. I've never had to use such a


p=NULL and *p='\0' mean quite different things. I hope there is no platform
that regards them as equivalent.

With respect to Phil's current coding style, the indenting occasionally
gets me, but as a maintenance programmer, I've got used to other people's
styles, and I try and submit patches in as close to that style as I can.

The memory management is clean, but under-documented at the moment[*], and
could benefit from a clear explanation of what is supposed to be happening
when, especially for some of the longer-lived bits of exim. Also, having
some idea of which bits can be long-lived (any init function) and which
are short lived (any of the actual route/lookup/authenticator functions,
for example (I use these because I've actually had cause to write my
own/modify existing ones of these)) would be good, as the differences are
subtle, and are currently in Phil's head (so you just ask on the exim-users
list).

[*] store_get and store_release, store_reset, etc. it's not clear what the
    differences are, and ending up with weird memory bugs because you think
    you know what you're doing is very easy.


In a lot of ways, the current model of a single binary is really clean,
and verifying the bits before it drops privs is not terribly hard. TMTATSNBN
is actually really hard to understand where you've got all these little bits
which are running as different users with differing access to things.

Especially once you've dealt with such things as MailScanner, it's a lot
easier to start understanding the semantics of the queueing and delivery
structure.

Cheers

MBM

-- 
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/