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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
