Confirmed | glpk should be compiled with -D_GLPLIB_HUGEMEM on AMD64

[Carthik Sharma]

Note: This bug was originally reported using reportbug to ubuntu-users.

---------- Forwarded message ----------
From: James Andrewartha <email address hidden>
To: Ubuntu Bug Tracking System <email address hidden>
Date: Wed, 19 Apr 2006 15:06:32 +0800
Subject: glpk should be compiled with -D_GLPLIB_HUGEMEM on AMD64
Package: glpk
Version: 4.8-1
Severity: important

When compiled on platforms where sizeof(void *) > sizeof(int), which
includes AMD64,
glpk should be compiled with -D_GLPLIB_HUGEMEM to allow allocating
more than 2GB (MAX_INT).
See the GLPK 4.5 changelog and
http://article.gmane.org/gmane.comp.gnu.glpk/1017.

-- System Information:
Debian Release: testing/unstable
  APT prefers breezy-security
  APT policy: (500, 'breezy-security'), (500, 'breezy')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-arcmsr-smp
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages glpk depends on:
ii libc6 2.3.5-1ubuntu12 GNU C Library: Shared libraries an

glpk recommends no packages.

-- no debconf information

[Steve Kowalik (stevenk)]

I have corrected this in the 4.10-1ubuntu1 upload of glpk.

[x (xk2c-deactivatedaccount)]

I have read down the upstream bugreport.
They are active working on this issue.

As the upstream bugreport tells there are some pros and cons in implemantion of the fix.

Which fix did we choose?

Copy from upstream bugreport:
-------------------------------------------------------------------------------
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
--------------------------------------------------------------------------

[x (xk2c-deactivatedaccount)]

...and if we have fixed it we should inform upstream, too.
means add a comment to their bugreport.