> >> 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 _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
