Freeradius-client some application development issues

[Alan DeKok]

Geoff Mitchell wrote:
>... The reason for having to use this older
> version of the library is because of seg faults caused by the use of the
> gethostbyname_r function, and the result set it returns. Now I believe in
> what freeradius.org does, and I am a big fan of the server, so I want to try
> and help clean this up to improve the library.

  Hmm... seg faults are bad.  That needs to be fixed.

> I am using Debian etch, and these problems could be specific to that distro.
> However, to start off the function gethostbyname_r is setting the returned
> h_addr_list, within the hostbuf, to the pointer tmphostbuf which the client
> library malloc's, and then free's within rc_gethostbyname. This causes a seg
> fault by the fact that the memory space has now been freed, and then
> accessed. There also seems to be another problem along these lines, because
> even removing the temphostbuf free results in a seg fault when the data is
> accessed in the function that called rc_gethostbyname, but not when accessed
> with the function. I am still trying to track down the cause of this second
> seg fault, hence why I have not submitted a patch.

  Ok, thanks.

> Another issue I have come across is the handling of the config file. Now I
> would like to use one config file for application specific, and library,
> values. This is not possible purely because of the way that find_options,
> which is called by rc_read_config, uses a hard coded value "NUM_OPTIONS".

  There is some work underway to enable an application to use the
library without any config file.

> Would you accept this value being moved into the rc_handle structure. This
> would then allow for the config_options to be expanded by the application,
> and thus a single config would work. At the moment expanding the options
> involves modifying the options.h and recompiling the library, that then
> makes it application specific.

  That would be fine, too.

  Please send a patch.

  Alan DeKok.