[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gsl] Possible error handling/return bug in vector/copy_source.c

From: Patrick Alken
Subject: Re: [Bug-gsl] Possible error handling/return bug in vector/copy_source.c
Date: Sun, 22 Sep 2019 21:41:59 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Yes you're right, thanks for catching this. I put the vector length
checks first now on the git. This code was just recently changed for
v2.6 to add the BLAS calls, so I overlooked that.


On 9/22/19 12:55 PM, Diego via Bug-gsl wrote:
> I've been playing with a wrapper for GSL for Chicken Scheme and I've found 
> what I believe might be a bug in the file vector/copy_source - do let me know 
> if I've missed something, because I'm extremely new to this code base. In 
> FUNCTION(gsl_vector, memcpy), the logic that checks that the length of the 
> vectors is equal falls under the #else clause.
> This means that (especially with no error handler set, as is recommended for 
> production code) if one of the other #if clauses is triggered during 
> compilation, memcpy will call a blas copy function instead, and can (and 
> will) fail silently - it calls the blas version /without/ returning, and then 
> goes on to unconditionally return GSL_SUCCESS. (In contrast, the memcpy in 
> matrix/copy_source.c checks the lengths before going into the #if/blas logic).
> For the proper errno codes to be returned, I would propose that either: a) 
> the vector length check and GSL_ERROR call should be before the first #if, as 
> in matrix/copy_source.c or b) each clause that ends up calling a blas 
> function should be using e.g. `return gsl_blas_dcopy(...)` so that the proper 
> error codes are returned. I think option a would be preferable for 
> consistency and so as to not have to rely on the internals of the gsl_blas 
> API.
> - Diego

reply via email to

[Prev in Thread] Current Thread [Next in Thread]