On Sun, May 16, 2004 at 12:18:13PM +0200, Malte S. Stretz wrote: > fed to the Message.pm ctor. I first couldn't believe it either, but it > works. I'll check it another time to be really sure though :)
Eww! ;) > of the message. Even if we undef @msglines after the ctor returns, we still > had that "spike" of memory usage. Yeah, but it's pretty much moot since when the parsing actually happens, there'll be a bunch of other "copies" in memory anyway via the parse tree, raw vs decoded vs rendered, etc. So having the array temporarily twice in memory isn't really a big deal. If we undef the first one after the parse() call, the memory will get freed and then get used by the full parse version. If we do the getline schwacky instead, the memory will eventually be used by the parse version. So as far as I can see, it'll be a wash at the end, so we may as well keep it clean and get to the same end point. > We also copied a whole potentially large array from A to B but I don't know > if that has much impact on performance. Well, it could theoretically be large, but in reality it'll be a max of ~300KB, which I doubt will be a problem anywhere. > But you're right, that bug is fixed, that's why I took this to the list ;-) :) > Nope, we can't put the size checking before we extract the Message-Id > because else we would have some random messages about mail with incorrect > sizes in the syslog for which the user can't find out which the culprit > was. I was figuring that since we couldn't trust the message data enough to scan it, we didn't want to trust that the header would be available. But either way I guess... -- Randomly Generated Tagline: "Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing." - Helen Keller
pgpDT3YEZfJpp.pgp
Description: PGP signature
