Re: mailutils (rf822 parser)

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> > is TBD, if useful. First I'll get the address stuff right.
> 
> - Header fields as part of <parse822.h> ok,  to merge it to
> header.[ch] is a little more complex, since the object

Uh, one of your earlier emails said "uncomment the functions
that parse headers" that I had left around. Are you now saying
you don't want to use them? :-) Anyhow, they're hanging about.

> - Parsing the receiving lines would be cool but probably not a
> high priority since no current programs care about it, perhaps
> the sieve stuff.

I'm pretty interested in Sieve, probably more interested than
time allows.

> > Also, return codes. The ones I've seen have mostly been:
> > 
> > 0 - success
> > +'ve - an error number
> 
> Yes this is our standard 
> 0 ==> success
> 0 != failed.
> 
> > What should I do, the possible return codes are:
> >   . no mem (ENOMEM)
> >   . function called incurrectly (EINVAL)
> >   . invalid rfc822 syntax found (ENOENT)

> >   . success (0)
> >   . success (with a count for how many successes)
> 
> I do not see how  this is usefull, you pass a string to be parse
> if it fails for xx reasons, it does not matter how far the
> parsing went the address is invalid.  The rest of the functions
> is to get info _get_comment(), _get_email(), _get_personal() etc ...
> You have them or don't.

Not quite. This is a valid address:

hi alain: ;

parse822_group() rightly returns success, but it doesn't create
and address right now... At a higher level, address_create0(),
I check this and change the EOK to an EPARSE (<- defined to
be ENOENT)... not exactly correct. Theirs some other things I
could do, but it's to late to talk about them now.

> > Gotta run, a friend's making me dinner, and love to have people
> > cook for me!
> 
> 8-).  I'm a very good cook  .. when camping.  I can make the most
> at of the least, you should taste my "cassoulet" dish .. 
> you probably do not want to know the ingredients though ;)

I used to eat the rum balls at the coffee shop I worked at for years,
nobody else could believe it. I figure, after it's cooked, the only
thing that matters is how it tastes (unless you're paying for it, then
appearance is important!).


I just ran my self tests, I parse all the addresses in Addrs (attached)
identically to before this round of changes, with the exception that
some addresses that could be parsed as valid up to some point are now
called bad.

address@hidden, address@hidden, boot=> pcount 2
-1 email <address@hidden>
-   local-part <OSULLIE> domain <rte.ie>
-2 email <address@hidden>
-   local-part <skidswam> domain <hotmail.com>
address@hidden, address@hidden, boot=> pcount 0

boot is garbage, so I turf the whole thing... what should the approach
be? Best effort, or "822 or nothing!".

address@hidden@dikke.penguin.nl=> pcount 1
-1 email <address@hidden>
-   local-part <rfunk> domain <wks.uts.ohio-state.eduofflinemailer-bounce>
address@hidden@dikke.penguin.nl=> pcount 0

I call that garbage now, too.


I'll be away for the weekend, I'll mail you something next week that's
more tidy, and contains a ChangeLog (but see top of parse822.c).

Also see attached my test program, is it useful enough to be squirreled
away in the cvs somewhere? I don't know if I've mailed you it before.

Good night,
Sam

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

parse822.c
Description: Text document

parse822.h
Description: Text document

address0.h.diff
Description: Text document

Addrs
Description: Text document

Addrs.test
Description: Text document

addr.c
Description: Text document