Re: mailutils parse822 and NL

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> Bonjour
> 
> > > but now imagine the Received field.
> > >  Received: ...
> > >  Received: ...
> > 
> > Received does have a specified meaning when it occurs multiple times.
> 
> Yick! Then that is another problem pending when I'll do the rewrite
> of header.c.  Now with header_get_value () there is no way to tell that
> the value was coming from multiple fieds that has been concateneted.

So do the Resent- headers, I think, each time you resend a message, you
add your resent- headers, I'd have to look up whether they go before
or after the earlier ones.

> header.c does not modify the string either, but merely keep the
> offsets of where things are.  The problem with strdups copy
> are space requirements, if you have a mailbox of 500 messages
> which is not that peculiar (mine is ~800 8-).  It can get heavy.
> So a trade off must be found.

I'd like to do this, unfortuneately I must modify the string while
parsing it (unescapeing escaped stuff, etc.). I should not do the
crazy one-char reallocs, but at the end of the day I still need to
duplicate strings. Notice address has an email field generated at
parse time from local-part and domain, this field doesn't need to
exist, that address can be generated on demand, and put into the
buffer the caller allocated. This will save some heap.

I'll add to my todo list...

> > Anyhow, the hard issue is LF/CRLF line termination, and the patch
> > won't work (for you) without dealing with this. I can make the whole
> > parser non-LF safe, by just pretending a bare LF is equivalent to a
> > CRLF, but that seems wrong to me. Am I not being pragmatic enough? Is
> > this just what all unix software does, RFCs be damned? Does anybody
> > really care that unix mboxes mangle certains kinds of data?
> 
> No, not all, this is why I was hesitant to change parse822 and asked for your
> feedback.  address_create () can take care of things and kosher the buffer
> before passing to parse822.  This would make porting to an OS like
> Window easier and we'll not have to change parse822() i.e. only
> address_create would know about the format use on the OS and parse822()
> does not have to worry about this. Besides, if one does not use 
> address_create()
> but rather prefer to use parse822_field_body() or parse822_field_name()
> the behaviour would be the same(I beleive parse822_field_body() kosher things
> by folding the line, also? i.e. parser822_field_body() and address_create()
> should have the same scheme).

Ok, I'm breaking down, a CRLF will be converted to LF when you save in
a unix mailbox, anybody who sends a bare LF through internet email is
destined for heart-break for more reasons than this little parser, the
folding done inside parse822 now treats a CRLF pair or a bare LF as
a new line.

This is simpler than doing it in address_create, and also after your
patch the rfc compliant "address@hidden,\r\n address@hidden" was not being 
parsed (the nl
was stripped, leaving a bare CR). I could fix this in address_create,
but I think the way to go is the attached patch. It should make
everybody happy as they can be!

> 
> After this exchange, do you still think I should apply you previous
> patch?  My opinion is no leave the old "\n" --> " "(minus memory leak 8) or
> fold the line on an "\n" or CRLF.

   ^^^^^ this is what the patch does (and reverse the changes in address.c
           since rev 1.9).

> But I'll let you have the last word, since you have a better
> understanding then I of the issues involve.

The real world is not exactly what the RFCs theorize it should be!

Sam

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