[Bug-gsl] FW: gsl version 1.5 - A few small source code issues

[Peter Rockett]

Another issue with compiling gsl version 1.5 on MSVC++ v6. Again,
utils/strol.c reports the following warning at line 45:

"unary minus operator applied to unsigned type, result still unsigned"

Basically, if the function is trying to convert a negative number string
it reverses the sign of the returned result (the variable, i). But i is
declared as UNSIGNED long int. It is difficult to see what sensible
conversion a compiler could apply in these circumstances (short of the
partial solution of checking the magnitude of i). Also, this code
appears to be K & R! Are these utility functions still needed? All seem
to be basic POSIX functionality.


Peter Rockett



-----Original Message-----
From: Peter Rockett [mailto:address@hidden 
Sent: 30 July 2004 19:38
To: address@hidden
Subject: gsl version 1.5 - A few small source code issues


A couple of small things in the source code of version 1.5:

1) In "utils/stroul.c". Shouldn't line 23 read:

#include "strtol.c" 

instead of 

#include <strtol.c>


2)The functions in the /util sub-directory seem to implement things like
memcpy() if you don't have a system-defined version of memcpy(), etc. A
small point but wouldn't these be better practice if they were guarded
by the preprocessor variables defined in config.h. For example, the gsl
version of memcpy() should be guarded by #if !HAVE_MEMCPY ... #endif,
etc. I think this should apply to strol.c, stroul.c, memcpy.c, memmove.c
and strdup.c. (I guess these may be fairly rarely functions used since I
think all the functions in /util are standard POSIX things anyway and
most compilers will have these as built-ins.)

Incidentally, shouldn't functions like gsl_vector_memcpy and
gsl_matrix_memcpy use the memcpy function for efficiency rather than
nested for-loops? If the compiler doesn't have memcpy then the version
in /utils would be called instead. Should the /util functions be
inlines, again for efficiency?

3) util/memcpy.c, utils/memmove.c and utils/strdup.c use the
HAVE_CONFIG_H preprocessor variable. I cannot see where this is set - is
this a now obsolete relic from an earlier version?


Best wishes,


Peter Rockett