Re: testing glpk 4.62 on a 64-bit platform

> >> This assumes that int never has more bits then size_t. This is not
> >> guaranteed. The x32 ABI uses 32bit addresses and supports 64bit integers
> >> (https://lwn.net/Articles/456731/). 

I'm using my own C compiler which supports 64-bit integers (long int)
and 32-bit addresses. This is a natural programming model for 32-bit
platforms that conforms to the ANSI C standard, and I still don't
understand why most existing C compilers provide 64-bit integers as long
long int rather than long int; at least there might be a compilation
option to choose between 32- and 64-bit long int.

> It depends on the compiler if int
> >> has 32 or 64bit.
> 
> I think Heinrich is right to be worried about this.

Please explain. Many glpk routines assume that sizeof(int) = 4 and will
just not work if sizeof(int) = 8.

> 
> > This wouldn't resolve the issue, because the glpk code supports only
> > ILP32 and LP64 programming models, where int is assumed to be 32-bit;
> > this is checked in the routine glp_init_env (see glpk/src/env/env.c).
> 
> However, it is easy to guard against this just in case. We can change
> the "if (sizeof(void *) != sizeof(size_t))" in minisat1.c to something
> like "if (sizeof(void *) != sizeof(size_t) || sizeof(int) >
> sizeof(size_t))" which should catch x32 variants with 64 bit ints.
> 
> As I said back in March, there is a C interface available for the C++
> MiniSat, so it may be possible to hook a more recent version to GLPK.
> I am planning to work on this at some point - if there is interest I
> can look into it earlier.

I wouldn't like to include a C++ code in glpk. It seems to me that a
better way would be to add an API routine that allows to set up an
user-provided CNF-SAT solver (which is, for example, minisat by
default).


Best regards,

Andrew Makhorin