Ok, I've got something fix-like ready ;) pkgTagSection::Scan() isn't really able to handle the case where \n\n isn't found in the string, it just lacks a way to report back this special error. Due to its design it also can't handle more than one buffer at once. Additionally pkgTagFile::Buffer has a fixed size of pkgTagFile::Size (defaulting to 32kb). So it would be hard to feed larger portions of data to pkgTagSection::Scan() anyway. So I've modified pkgTagFile::Fill() (the function that fetches the data from the tag file and stuffs it into Buffer) to check if Buffer actually contains a double newline sequence after the read(). If it's not found the buffer size is doubled (new double-size buffer is allocated, data copied over, old one is deleted). Then another read is tried, and double NL search starts again. This is done on loop, until there is no more data to read, or a double NL is found. The new Fill() remembers which area of Buffer have already been scanned, and avoids rescanning them. Shrinking of the buffer is not implemented. It will be deleted anyway, once the pkgTagFile object is destroyed itself. Also I don't expect Buffer to grow extremely large. We didn't hit this bug until now that sid's Release file grew > 32k. So 64k should be enough for some time again. The only significant overhead that my fix has is the copying of the data from the old to the new Buffer. If it turns out that this will be a problem (which I really don't believe, since even for 1Mb release files we only do 5 loops: 32*2^5) we could use a list/vector of buffers and then do the memcpy()'ing all at a time. This way we wouldn't copy the same data at the beginning of Buffer around all the time. The fix compiles and works fine here, it's available as Greek0@gmx.net--2005-main/apt--debian--0.6--patch-4 at <URL:http://greek0.net/~greek0/archives>. Cheers, Greek0 PS: Not yet tagged +patch, since I think that I could perhaps come up with a nicer fix sometime soon.
Attachment:
signature.asc
Description: Digital signature