From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14845 invoked by alias); 9 Sep 2013 17:50:45 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 14831 invoked by uid 89); 9 Sep 2013 17:50:43 -0000 Received: from ipmx6.colorado.edu (HELO ipmx6.colorado.edu) (128.138.128.246) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2013 17:50:43 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.2 X-HELO: ipmx6.colorado.edu From: Patrick Alken X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACUKLlKMrLMp/2dsb2JhbABbgwfALIJ1gSQWdIIlAQEFOEARCxgJEwMPCQMCAQIBNwENEwgBAYd+uymIMZAHFoQHA4k1lFiLToM/HQ Received: from bonanza.ngdc.noaa.gov ([140.172.179.41]) by smtp.colorado.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Sep 2013 11:50:40 -0600 Message-ID: <522E0A6F.3040400@colorado.edu> Date: Mon, 09 Sep 2013 17:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: Issue with Mathieu Function Code References: <522231C2.1060908@gladman.plus.com> In-Reply-To: <522231C2.1060908@gladman.plus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q3/txt/msg00003.txt.bz2 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 >