Mailing List Archive

Any outstanding patches for spam[cd] floating around?
Moin,

I'd like to kick some parts of the codebase, especially spamc and spamd,
through a reformatter so the style gets consistent and better to
understand. The coding style was discussed some weeks ago, I'll update the
Wiki accordingly before I start.

As this can cause some headaches with outstanding patches, anybody who's
still got stuff to commit for spamc or spamd should speak up within the
next two weeks or so.

Cheers,
Malte

P.S.: Most of the bugs blocking 3.0 are SQL-related. What do you think about
cutting an alpha version (without optimized scores) so we can get some more
testers for the new stuff on board?

--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Malte S. Stretz writes:
> Moin,
>
> I'd like to kick some parts of the codebase, especially spamc and spamd,
> through a reformatter so the style gets consistent and better to
> understand. The coding style was discussed some weeks ago, I'll update the
> Wiki accordingly before I start.
>
> As this can cause some headaches with outstanding patches, anybody who's
> still got stuff to commit for spamc or spamd should speak up within the
> next two weeks or so.

I already did this a couple of months ago (in spamc code at least),
using the ASF coding style "indent" rules.

One thing I'd like to get into spamd would be a better architecture for
where user configs get read. Big sites perpetually have to hack spamd to
get it to use virtual user configs/configs from SQL/configs from LDAP/for
all users/ some subset of users/with a shared bayes-storage dir/with a
per-domain bayes-storage dir/etc. etc., repeat ad infinitum.

It's messy, and IMO, a plugin API that they can use instead of the current
patchwork of command-line options, would be better. I haven't put any
time into thinking about it though.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAtk0mQTcbUG5Y7woRAoEXAKDcDih2xEWNFBFVmXEFs3ExwpOfggCgtZJq
lLS9qrt0bh0o4SWP1K+g/U8=
=Hw6i
-----END PGP SIGNATURE-----
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
On Thursday 27 May 2004 22:18 CET Justin Mason wrote:
> Malte S. Stretz writes:
> > Moin,
> >
> > I'd like to kick some parts of the codebase, especially spamc and
> > spamd, through a reformatter so the style gets consistent and better to
> > understand. The coding style was discussed some weeks ago, I'll update
> > the Wiki accordingly before I start.
> >
> > As this can cause some headaches with outstanding patches, anybody
> > who's still got stuff to commit for spamc or spamd should speak up
> > within the next two weeks or so.
>
> I already did this a couple of months ago (in spamc code at least),
> using the ASF coding style "indent" rules.

Oh, right. I just had a short glance at the code and some comments are
wrongly indented thats what made it look weird to me :)

I'll change the rest of the "if (const = var)" to the more readable "if (var
== const)".

> One thing I'd like to get into spamd would be a better architecture for
> where user configs get read. Big sites perpetually have to hack spamd
> to get it to use virtual user configs/configs from SQL/configs from
> LDAP/for all users/ some subset of users/with a shared bayes-storage
> dir/with a per-domain bayes-storage dir/etc. etc., repeat ad infinitum.
>
> It's messy, and IMO, a plugin API that they can use instead of the
> current patchwork of command-line options, would be better. I haven't
> put any time into thinking about it though.

Yes, I know. It was one of the top things on my todo list and I already put
some planning behind it. But then I was "distracted" by other stuff and my
proposed but never finished Conf.pm rewrite delayed other things already
enough so I decided to drop it for 3.0. And I doubt that I [wc]ould finish
it anyway.

If anybodys interested in what I thought about, I can try to phrase my
thoughts and plans though. That's always the hardest part ;-)

Cheers,
Malte

--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
--On Thursday, May 27, 2004 10:32 PM +0200 "Malte S. Stretz"
<msquadrat.nospamplease@gmx.net> wrote:

> I'll change the rest of the "if (const = var)" to the more readable "if
> (var == const)".

Is that an Apache style thing? I always code constants on the left, to
catch just the typo you made in your example.
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
On Thursday 27 May 2004 23:45 CET Kenneth Porter wrote:
> --On Thursday, May 27, 2004 10:32 PM +0200 "Malte S. Stretz"
>
> <msquadrat.nospamplease@gmx.net> wrote:
> > I'll change the rest of the "if (const = var)" to the more readable "if
> > (var == const)".
>
> Is that an Apache style thing? I always code constants on the left, to
> catch just the typo you made in your example.

No, code written the other way round is just butt ugly and insaneously hard
to grok. Maybe you can avoid the error of accidently assigning a var
instead of comparing it, but it makes reading and debugging code a tough
job which is worse than a bug in the first place. At least that's my
experience.

Especially because the "trick" with writing those the other way round just
works as long as you compare a const to a var. If you compare two vars, it
won't help so you must not rely on this cathing your typos.

Instead, current versions of gcc (and I guess Intel, Microsoft and Borland
compilers do so, too) do warn you if you write something like "if (var =
1)" -- you have to write "if ((var = 1))" if you really want to do that.
Which you shouldn't do anyway as it makes code harder to understand, too.
Better is "var = 1; if (var) ..." (in two lines of course).

Cheers,
Malte

--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
Kenneth Porter wrote:
> I always code constants on the left, to
> catch just the typo you made in your example.

It gets to be a religious argument. The two sides are:

1) It catches a common typo that is hard for the eye to notice and is
hard to debug.

2) It looks ugly and any decent compiler will issue a warning if it sees
an assignment in an if conditional.

I think that the second side has the compelling argument, but only if
the compiler that is used cooperates. Which all compilers I know of do
if you set the options correctly.

Compiling with full warnings on and then getting rid of anything that
generates a warning is a great way of catching obscure bugs, even if not
every warning is caused by a bug.

-- sidney
Re: Any outstanding patches for spam[cd] floating around? [ In reply to ]
> I'll change the rest of the "if (const = var)" to the more readable "if
(var

If you aren't inheren'tly a C or C++ guy, be aware that there is a valid
reason for this ugly coding style. It is really easy to type = instead of
== in an expression, and in most compilers you won't get a warning out of
this, the code simply will be badly broken. This is if you have the
variable in the left. If you have the constant on the left, you will get a
syntax error out of that slip, as assigning a value to a constant is illegal
in C/C++.

Now, I'd be in favor of swapping the code around to be less ugly too, were
it my project. But you have to be aware you are opening the door for
subtile bugs by doing that. It may or may not be an appropriate thing to do
in a open source project with many contributors.

Loren