attachments and binary data

David Relson relson at osagesoftware.com
Tue Nov 30 02:52:16 CET 2004


On Mon, 22 Nov 2004 19:35:12 +0300
Evgeny Kotsuba wrote:

...[snip]...

> and it was "stable" release :-/   I have note that 0.15.8 crashes and 
> 0.17.5  can go into very long cicles in lexer??3.c , where it   does 
> things like 
> char * source =...
> char *dest =....
> // actually source is equal to dest  and NN is ~100K
>   for(i=0; i< NN, i++) *dest++ = *source++
> 
> SY,
> EK

Hi Evgeny,

Thanks for the test case you sent me and the lexer_v3.c modification to
show the problem.  

It _is_ the case that this mime part:

------------791891673B6A210E
Content-Type: application/x-zip-compressed; name="blablabla"
Content-Disposition: attachment; filename="blablabla"
Content-Transfer-Encoding: base64


is causing the lexer to read in a big chunk (200K or so) of the
attachment.  On my AMD 2800, it takes about 30 seconds to process the
448k attachment.  We'll have to see what we can do to prevent that
happening.

Also, as you found, the flex code is doing a lot of unnecessary copying.
The loop looks like:

   for (i=0; i<number_of_bytes; i++)
     *dest++ = *source++

and would be much faster if coded as:

   if (dest != source)
      for (i=0; i<number_of_bytes; i++)
        *dest++ = *source++

Unfortunately, that loop is code provided by flex and we can't change
it.

Anyhow, I'll do some experimenting and see what can be done about the
(unnecessary) processing of the attachment.

Regards,

David
 



More information about the bogofilter-dev mailing list