> I looked over GLPK according to data size neutrality guidelines at > http://www.unix.org/whitepapers/64bit.html > I didn't see any problems in the GLPK code other than the data types in > umalloc, ucalloc, and ufree. > > Now that I have a better understanding of this situation, I agree that > switching the types to size_t is the correct solution, and I think it is > all that is required. That will match the normal malloc prototype. > > However, Andrew Makhorin (upstream author) noticed the bug report and > emailed me about why he prefers not to do this. > >> As I understand you suggest using size_t rather than int in glpk >> memory allocation routines (umalloc, ucalloc, ufree). Undoubtely this >> is quite correct, however, this may cause portability problems; in >> particular, it may be impossible to print a value of size_t type via >> printf. ISO C specifies appropriate formats (via #define's) to be used >> in printf, however, many C/C++ compilers still does not support them. >> >> So I think to use double for such purpose. On IEEE machines this >> allows representing integer values up to 2^DBL_DIG-1 = 2^53-1 that >> much greater than the memory volume of any modern computers (about >> 9000 terabytes). > > This is relevant in error messages that appear in umalloc, ucalloc, and > ufree. Looking into this issue, I found a few discussions addressing > similar issues: > http://www.thescripts.com/forum/thread221518.html > http://gcc.gnu.org/ml/gcc/2001-07/msg01039.html > > Apparently this was addressed in the C99 standard. > > The two most likely solutions are: > > 1. Switch to size_t. In the printf statements, use %zu according to > the C99 standard. There may be some portability issues for systems that > aren't standard-compliant. > > 2. Switch to size_t. In the printf statements, cast the values to > unsigned long and use %lu. > > In either case I don't think it makes sense to have umalloc and ucalloc > have types that differ from malloc and calloc. > > Andrew, do you think one of these solutions would be appropriate to > implement upstream, or is there another reason you prefer not to do one > of them? > > Brady
Hi Brady, Let me try explaining some source points. Writing glpk code I kept in my mind some assumptions in order to make the code as portable as possible, namely: CHAR_BIT = 8 (as stated in ISO C as well as in GNU C) sizeof(char) = 1 sizeof(int) >= 4 (i.e. at least 32-bit integers are assumed; however the code must work without changes if sizeof(int) would be 8 or more) sizeof(void *) >= sizeof(int) (even in umalloc/ufree) sizeof(double) >= 8 (i.e. at least 64-bit floats are assumed) short int's are never used (except glpavl to represent some flags) long int's are never used at all unsigned int's are never used (except unsigned char) i.e. in glpk code only four hardware types are used: char, int, double, and ptr; besides, ptr's are never casted to int's and vice versa. Int's are used for only two purposes: as flags (i.e. as small integer values) and as dimensions and arrays indices. I do not think that even in 64-bit mode there would be a need to use integers larger than 32 bits, because even 32-bit integers being used as array indices are able to access about 2*10^9 entries. (However, some limitations must be introduced to prevent fixed-point overflow if someone will try loading a gigahuge model in 64-bit mode :) This, of course, does not mean that glpk is not able to use more than 2Gb, because 32-bit integers are sufficient to index arrays in matrix routines while other glpk components use linked lists rather than arrays. I think using size_t in umalloc/ufree is a best solution. However, my pc is still 32-bit pentium, so currently I would be not able to test the code in 64-bit mode. Best regards, Andrew Makhorin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
