Re: Issue with Mathieu Function Code

[Patrick Alken <patrick.alken@Colorado.EDU>]

This sounds like a good idea, but we need to maintain binary 
compatibility in future releases of GSL. It seems we could easily add 
functions with _e names, since they are already implemented. But we need 
to maintain the old interfaces as well, or at least mark them as 
deprecated, so that people can link their programs to the new library 
version without needing to recompile.

This would be a good thing to add to a list of features for v2.0. I 
think Brian Gough had planned to break binary compatibility for v2.0 and 
do all these sorts of things that needed doing.

Patrick

On 08/31/2013 12:11 PM, Brian Gladman wrote:
> The GSL special functions are each supposed to have two alternative
> functional interfaces, a pure one:
>
> double function(x, ...)
>
> and one allowing for full error returns:
>
> int function_e(x, ...  gsl_sf_result * result)
>
> But the Mathieu function code doesn't follow this convention.
>
> It doesn't offer the former interface at all and uses the second
> convention for all its functions BUT without the '_e' name extension on
> its function declarations.
>
> This is quite error prone since it is easy to assume that *gsl_sf_result
> is simply a reference to a double when in fact it is a structure that is
> longer than this (a library user on Windows made exactly this mistake
> and wondered why his code was causing an illegal access exception).
>
> I am doubtful that this is an intentional feature of the Mathieu
> function code so I have created the attached patch to update the code to
> use the normal conventions of the GSL special functions.  (this needs
> testing since I have only tried it on WIndows).
>
> If this is adopted, the documentation will need updating as well
> (unfortunately I am unable to do this).
>
>    with my best regards,
>
>        Brian Gladman
>