Re: mailutils (rfc822 parser)

[Sam Roberts]

I've a patch that addresses most of the stuff we talked about,
everything but the return codes, better memory management, and
a test suite to root out leaks. Also incorporated your patch.

Also, parsing rfc822 header fields, dates, and received lines
is TBD, if useful. First I'll get the address stuff right.

It's a lot of textual changes, and I retabbed to a 2char shift
width, and an 8char tab. It's a big diff, do you want a diff,
or the whole file? I guess I can just send both, and you can
choose.

Also, return codes. The ones I've seen have mostly been:

0 - success
+'ve - an error number

What should I do, the possible return codes are:
  . no mem (ENOMEM)
  . function called incurrectly (EINVAL)
  . invalid rfc822 syntax found (?????)
  . success (0)
  . success (with a count for how many successes)

In the absence of precedent, I'd go for >= 0 being some
variety of success, with 0 being the success value in
the absence of a count, and -ve being an errno.

Should, instead, I add a reference argument, where the return
number can go, so that return values are 0 (ok) or a +ve
error number?

And what errno should I use to report on rfc822 parsing errors?
I like to use system errnos for my apis, too, since it means
I don't have to map the system error numbers to my own scheme,
but sometimes it means you have to grap a strange one. I figure
ENOENT isn't so bad, its unambiguous (for the parseing functions),
and even vaguely related. I could also define my own, EPARSE,
and maybe define it to be ENOENT (so it doesn't collide with
anything).

Oh, and where should "parse822.h" go? It might be
in the public <mailutils/parse822.h>, but wherever's
useful to you.

Gotta run, a friend's making me dinner, and love to have people
cook for me!

Salut!
Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)