Hello Mark, MW> Maybe I'm being more dense than normal today, but I'm having trouble MW> understanding the AVC_NotSupported return value. Does this imply that MW> *all* the functions must at least have dummy code that returns a value MW> of AVC_NotSupported?
No. If you don't implement a function, you can simply don't implement it. But - it may be needed for debug purposes or when a plug-in is used as a proxy to some engine. MW> What is the difference in, for example, MW> BAV_StreamChecking() returning AVC_Error vs AVC_NotSupported? Semantically, there is no difference now, but this may change in future. MW> My understanding is that I should return AVC_OK if my plugin supports MW> stream checking. If my plugin does not support stream checking then I MW> should return AVC_Error. When would I *ever* want to return a value of MW> AVC_NotSupported? If your plug-in is a proxy to some AV engine which may or may not support stream checking depending on its version, for example... MW> Secondly, the Msg argument to BAV_CheckMemory(), BAV_CureMemory(), MW> BAV_CheckFile(), BAV_CureFile, BAV_CheckStream(), and BAV_CureStream() MW> is specified as never being allowed to exceed 1024 bytes - why is MW> this? Because otherwise a complex mechanism should be involved to avoid performing twice such a resource-consuming operation as checking for viruses. Complexity may result in bugs on any side, so it's better to use limitation here. There is also buffer-overrun possibility here (sorry Leif - I was lying because I didn't remember it before I actually looked at the code) which is fixed in the oncoming version. MW> Not that I would expect to exceed this value, but I'm worried MW> that there's a buffer in TB itself that would overflow if I passed, MW> say, 4096 bytes as a result. Hmm. Potentially, any plug-in may crash TB or damage its data. So, better to make sure all operations are bound to documented limits :-) MW> What happens if the message is malformed, MW> ie, not null-terminated? Will this cause TB to crash? If it's not null-terminated, not a problem - it'll be cut automatically. MW> The documentation states that for these functions "Usually AV software MW> returns a distinguished name of the virus of the message." What does MW> usually mean in this case? Usually means that most of known AV engines we were testing or created simple BAVs for. MW> What does TB do with the returned string? The string is added to the log. MW> Lastly (at least for now) what is the difference in the BAV_Curexxx MW> functions between AVC_CantBeCured, AVC_VirusFound, and AVC_Error? AVC_Error always means that error occurred, i.e. the object cannot be checked for some reason. In this case, the object will be processed as if no virus found... Currently, AVC_CantBeCured and AVC_VirusFound are treated in the same way - i.e. it means that the object cannot be cleaned. -- Cheers, Stefan ...Calm down - it's only ones and zeros! ________________________________________________ http://www.silverstones.com/thebat/TBUDLInfo.html
