On Mon, 31 Mar 2008, Sven Schreiber wrote:
This comment/question may be unnecessary, and I confess I don't
know the details of what I'm talking about, but just to make
sure:
I just read somewhere that "long" integers are not only
different between 32-bit and 64-bit platforms (in general), but
that that difference also depends on the OS, so that the change
from 32-bit Linux to 64-bit Linux is not the same as from 32-bit
Windows to 64-bit Windows.
If that affects gretl at all, I presume that Allin is aware of
that, but I guess there may be a small probability that he's
not, hence this message.
Thanks for the note. I _think_ we should be OK since the changes
made for gretl 1.7.3. The place where trouble was coming up was
the use of "long" for integers defined in connection with lapack
(array sizes and so on). What I hadn't fully understood before
was that
(a) on most (I'd say "all", but some oddity would surely bite me
in the bum) 32-bit platforms, "long" is a 32-bit value, and is
plain "int".
(b) Fortran 77 uses a 32-bit type called "integer".
(c) Old-style Fortran/C conversions -- including the "f2c.h"
header in gretl, before 1.7.3 -- translate Fortran "integer" as C
"long". I guess this is a historical thing, to try to avoid
getting a 16-bit value. It's harmless on 32-bit systems but can
break lapack compatibility on 64-bit systems, where long may be
a 64-bit type.
What we now do is include <stdint.h> and define "integer" as
int32_t. This should ensure we get 32-bit integers to feed to
lapack, on any platform that gretl supports.
Allin.