[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gsl] Possible error handling/return bug in vector/copy_source.c
From: |
Diego |
Subject: |
[Bug-gsl] Possible error handling/return bug in vector/copy_source.c |
Date: |
Sun, 22 Sep 2019 18:55:32 +0000 |
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
- [Bug-gsl] Possible error handling/return bug in vector/copy_source.c,
Diego <=