[Openvas-devel] Changes to cache file handling

Stjepan Gros sgros.ml at gmail.com
Sat Jan 10 10:29:57 CET 2009

On Fri, Jan 9, 2009 at 11:23 PM, Jan-Oliver Wagner
<jan-oliver.wagner at intevation.de> wrote:
> On Freitag, 9. Januar 2009, Stjepan Gros wrote:
>> > My changes to store_plugin and store_load_plugin
>> > allow to have arbitrary paths for filename. So you can
>> > combine subdir and filename when calling the function.
>> > (Perhaps use g_build_filename() for this).
>> I can't remember why I did this that way (i.e. that subdir is
>> separately handled). Probably there could be some optimization in
>> combining the subdir and filename. But, one of the possible problems,
>> as I remember, is that implicit include dir is subdirectory, relative
>> to a top level plugin directory, where plugin resides. If I combine
>> the two (filename and subdir) than I have a problem to get back subdir
>> in order to put it into a list of include directories.
> Directory "." can easily be determined by removing the filename.

At this point this is obviously equivalent, either subdirectory is
handed explicitly or it is determined implicitly.

> Directory "/" for the plugin dir can't. But thats not necessary,
> because this directory is (should) always be set via store_init().

I just saw that you depricated store_init_{user,sys} which is good.
This functions confused me as I didn't know what is their purpose.
Anyway, I'm not very fond of global variables, and IMHO, I would
remove them, but there could be advantages to their use. So, I'll
leave this decision to you.

And while I'm at deprecated functions that can not be removed until
next major release it could be good to mark them as deprecated so that
people know that and also, when the time comes for removal, that they
are not forgotten. There is an attribute supported by gcc,
__attribute__ ((__deprecated__)), that can be added to the deprecated
functions so that compiler clearly warns about those functions when
they are used.

> But maybe there are other good reasons for doing so. Once we find
> one it is fairly easy to switch to the subdir idea. For the time being
> I thought it would be good to not break API.

I think there are no more reasons for subdir parameter, especially
when you can deduce what it is from the filename of a plugin. Anyway,
I haven't had in mind the API compatibility, so maybe if I did, I
would probably do it the way you did.

> BTW: Have you tested how your patch works for dependencies on other
> NASLs?

Hm, I tried to load all the NASLs that are in trunk and that worked. I
don't know is that the question, or you mean something else?


More information about the Openvas-devel mailing list