On Thu, Mar 12, 2009 at 12:34 PM, Tomasz Kojm <tk...@clamav.net> wrote:
> On Mon, 02 Mar 2009 12:39:47 +0300
> Eugene Crosser <cros...@average.org> wrote:
>
>> To mitigate this problem (if you *really* want to get rid of cl_limits
>> structure exposed to the user), you might introduce separate pairs of
>> accessor functions for different types of arguments, e.g.:
>>
>> cl_engine_{get|set}_size(...,uint64_t *val)
>> cl_engine_{get|set}_int(...,uint32_t *val)
>> cl_engine_{get|set}_str(...,char *val)
>>
>> This way, there will be no chance to pass the argument of wrong type.
>
> Hi Eugene,
>
> Thanks for your email and suggestions. While the original functions
> were very generic, they could indeed lead to some confusion.
> Therefore I replaced them with the following set:
>
> extern int cl_engine_set_num(struct cl_engine *engine,
> enum cl_engine_field field, long long num);
>
> extern long long cl_engine_get_num(const struct cl_engine *engine,
> enum cl_engine_field field, int *err);
>
> extern int cl_engine_set_str(struct cl_engine *engine,
> enum cl_engine_field field, const char *str);
>
> extern const char *cl_engine_get_str(const struct cl_engine *engine,
> enum cl_engine_field field, int *err);
>
> These functions eliminate some possible programming errors and
> limitations of the old ones, eg. cl_engine_get_str doesn't require
> a buffer anymore; it's also much easier to set values with
> cl_engine_set_num.
>
>> And here we are coming to my second concern. By requiring the the user
>> to use bit-size-specific types (uint32_t, uint64_t), you force them to
>> deploy all the dark magic of having these types defined portably on
>> different systems, and to essentially duplicate the logic implemented in
>> cltypes.h. I believe that there is no good reason for that. While there
>> may be necessary to have bit-size-specific types *inside* clamav, having
>> them leaking through the API is not justified, in my opinion. I think
>> that it would be "cleaner" to use more common types in the API, like this:
>
> The new functions use 'char *' and 'long long' for handling the values
> so this issue should be solved as well.
>
>> And a final note: I think it's worth mentioning in the documentation
>> what is the relation between "options" passed to cl_init() and "options"
>> passed to scanning functions. If they are different, maybe it's better
>> to name them differently, like "init_options" and "scan_options".
>
> I renamed them, too.
Hello Tomasz,
Since API was chenged one more time, a new RC will be released to
0.95? I'm just asking it because I maintain clamav at FreeBSD ports
and I tested all dependant ports with clam 0.95-RC1 and notified
maintainers of all ports that doesn't build with new API to fix it. I'm just
wondering if with these new changes those ports can or not break
again.
Thanks
--
Renato Botelho
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
