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

[Patrick Alken]

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.

Patrick

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
>
>
>