I removed it from my tree. On Monday I'll bombard Ilja with patches that remove these functions and let him know to remove injector.c.
Jesse, you'll be interested to see the results of my \r\n counting... mysql> select id, messagesize, rfcsize from physmessage order by id; +----+-------------+---------+ | id | messagesize | rfcsize | +----+-------------+---------+ | 71 | 1720404 | 1770830 | // All newlines counted on delivery | 72 | 1720404 | 1720409 | // Only non-\r\n counted on delivery | 73 | 1720404 | 1770829 | // Dbmail-imapd counting on first read +----+-------------+---------+ The command line I'm using to generate this message is... cat headers.txt HugeOthello.txt | ./dbmail-smtp -n And the "official" line counts for the files in question... [EMAIL PROTECTED] dbmail-2.0rc2-fixes-snap2]$ wc headers.txt HugeOthello.txt 5 9 104 headers.txt 50420 300440 1720300 HugeOthello.txt 50425 300449 1720404 total Notice that the rfcsize calculated by dbmail-imapd is exactly 50425+1720404, i.e. it's exactly the total bytes plus the total lines, regardless of \r\n status. The Othello corpus in question if from Project Gutenberg, and therefore in fact already has \r\n pairs on each line... [EMAIL PROTECTED] dbmail-2.0rc2-fixes-snap2]$ file HugeOthello.txt HugeOthello.txt: ASCII English text, with CRLF line terminators So my understanding of this is that my original all-newlines-counted on delivery algorithm was erroneously counting the very last blank line, which is really most likely the end of file line, so that's trivial to correct. The dbmail-imapd count is just a blind all newlines count, too, but it doesn't have the end of file line. So at least I got my count working about the same as the existing count ;-) But the kicker is that those lines should not have been counted, they already have \r\n pairs! I'm going to stick to my new algorithm, which counts only non-\r\n lines upon delivery and appears to be counting correctly. Ilja, when you're back in the office, better get ready for patch madness! :-P Aaron Feargal Reilly <[EMAIL PROTECTED]> said: > Funny, I was looking at that just last night, as far as I can see, it can be removed from the distribution. It's a legacy from the defunct mini-injector I believe. > > -fr. > > On Fri, 27 Feb 2004 16:47:08 -0000 > "Aaron Stone" <[EMAIL PROTECTED]> wrote: > > > > > So I'm working on the rfcsize thing, and noticed that in header.c, there are > > two functions for reading headers: read_header() and read_header_process(). > > The latter seems to basically build the functionality of mail_adr_list() > > into > > the header reading mechanism. The only consumer of this function is > > injector.c, which looks like a half-rewrite of the old main.c/dbmail-smtp. > > While I like the name injector much better than smtp, since it's more > > accurate > > about describing what the program does, afaict, injector.c is an ancient > > artifact and we can remove the read_header_process() function from header.c > > (it's also a bit more complicated code in there, so adding the rfcsize > > counter > > looks a bit harder). > > > > Uh, short version in English: > > injector.c, do we need it? > > read_header_process(), can we remove it? > > > > Aaron > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > -- > Feargal Reilly, > Codeshifter, > Chrysalink Systems. > > --