after working through the libclamav code and tightly reading the list archives, I (too) noticed some drawbacks with the current code.
This mail is just to (re-)start some discussion on how to make clamav a better product (it is already very good as for being open source and handled by just a hand full of core developers), and not to offend anyone.
1. There are some performance and code penalties in the lib. It's just that the lib was designed (or growed) to work on file descriptors. Besides from being non-buffered it has to use chunky read()s and memmove() to scan a file in (overlapping) buffers. Also some add-on modules, like the mbox-, zip- and rar-code, need some extra fiddling (FILE* from fd and vice versa), which are not done properly [patches for that sent to Tomasz, but not yet checked in].
I'd like to redo libclamav to work on memory buffers (using mmap() where possible). At least on the platforms I worked on, Linux and Solaris, this is a very fast alternative to unbuffered stdio.
2. Switch from PThreads to fork()/exec() [I can already hear you! :-)]. It is no news that the current code leaks memory and is missing cleanup handlers at thread exit. With the current code layout, I'd say it would be easier to switch to fork than do the cleanup stuff properly.
3. Add some more archive handlers. At least tar, LHA and ARC. I know it may sound a bit foolish given (my own) discussion about recoding libclamav, but such archives _do_ exist, and clamav failed badly when it came to archive support in the german iX magazine (iX 5/03, Page 116). Too bad the article is not available online.
Hope it will be a nice discussion...
Thomas
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Clamav-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-devel
