[Olsr-dev] Open issues for next release (was Re: OLSRD RT refactoring)

[Sven-Ola Tuecke]

Hi Bernd,

I'm no 64 Bit expert, but an int should fit into a pointer on any CPU (but
vice vesa may fail for upcoming 256 bit CPUs). OK, Parameter int -> void*,
then cast to int if needed. Did you accept a patchfile or will you do it
for yourself?

// Sven-Ola

Bernd Petrovitsch wrote:

> On Wed, 2007-09-05 at 18:41 +0200, Bernd Petrovitsch wrote:
> [...]
>> Everyone please test (especially on non-Linux systems) and report.
>> I'm considering a release in the next few days if nothing serious shows
>> up.
> 
> One issue crept up (so far): the hack for the nameservice plugin to have
> a function
> called for all parameters uses the "int addon" parameter to pass a "char
> *" (the -
> in this case unknown - name of the parameter).
> 
> This gives warnings on 64bit architectures since there is no guarantee
> that a "void *"
> fits in an "int".
> Apart from the fact I consider the solution a hack in the not so good
> sense, I see
> the following possibilities:
> - if possible: fix the parameter definition to simply avoid the
> necessity of that
>   "solution".
>   That requires changes in the (deployed) olsrd.conf files is is - thus
> - probably.
> - add another function to handle otherwise unhandled parameters (for
> such situations).
>   That somewhat undermines the purpose of the table for the parameters
> (but I wasn't
>   aware that this exists).
> - explicitly pass the parameters name to the called function (though it
> is not used by
>   n-1 of them).
>   But this would open the possibility to allow wildcards or regexps in
> the parameters
>   "name" there.
>   Current drawback: I don't know how to handle regexps on Win32 (and I
> didn't look into
>   equivalents of fnmatch(3)) - the nameservice plugin is only because of
> this disabled
>   on Win32 BTW.
> 
> Bernd