[Bug libc/13575] New: SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[Bug libc/13575] New: SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[soltys at ziu dot info]

http://sourceware.org/bugzilla/show_bug.cgi?id=13575

             Bug #: 13575
           Summary: SSIZE_MAX defined as LONG_MAX is inconsistent with
                    SIZE_MAX, when __WORDSIZE != 64
           Product: glibc
           Version: 2.15
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: soltys@ziu.info
    Classification: Unclassified


long <type> has always higher rank than <type> even if both have the same
representation. When __WORDSIZE is not 64, SIZE_MAX uses (unsigned int) type in
constant explicitly, but SSIZE_MAX falls back to LONG_MAX which is (long int) -
which is different (higher) rank than (int) or (unsigned int).

Consider following example on 32bit architectures:

#define  _POSIX_SOURCE 1
#include <stdio.h>
#include <limits.h>
#include <sys/types.h>

int main(void)
{
        ssize_t x = 10;
        printf("val: %zd\n", SSIZE_MAX - x);
        return 0;
}

if compiled with gcc -Wall test.c
The compiler will issue warning:

test.c:9: warning: format ‘%zd’ expects type ‘signed size_t’, but argument 2
has type ‘long int’

So - when __WORDSIZE is not 64 - shouldn't SSIZE_MAX be defined as INT_MAX to
be consistent with SIZE_MAX (the change also fixes warning in the above case) ?

The problem doesn't happen when __WORDSIZE == 64, as in such case types are
(unsigned long int) and (long int) for SIZE_MAX and SSIZE_MAX respectively.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13575

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-01-09 11:56:18 UTC ---
There is no guarantee that ssize_t is the signed type corresponding to 
size_t - and you can't safely change types between int and long because 
that would change the C++ name mangling.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13575

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Ulrich Drepper <drepper.fsp at gmail dot com> 2012-01-09 18:45:19 UTC ---
What has this to do with glibc?  The type definition and the warning come from
gcc.  Don't file bugs here if you don't know what you're doing.  Bother your
distribution maker, it's their job.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[soltys at ziu dot info]

http://sourceware.org/bugzilla/show_bug.cgi?id=13575

--- Comment #3 from Michal Soltys <soltys at ziu dot info> 2012-01-10 01:29:02 UTC ---
@Joseph

Thanks for clarification about size_t/ssize_t sizes.

@Ulrich

But for ssize_t type, the definition comes from glibc headers, not gcc. Apart
from what Joseph clarified - what I meant in context of SSIZE_MAX was analogous
(even if regarding the very opposite thing now) as in:

http://sourceware.org/ml/libc-hacker/2002-08/msg00031.html

that solution seemed more proper with reference to how ssize_t
is defined in glibc headers, which for __WORDSIZE == 32 always comes down to
(int), unless overriden locally. If SSIZE_MAX constant is to accurately reflect
ssize_t type, then that would be more correct than just defaulting to LONG_MAX
unconditionally ?

Thanks for the reply, even if a rough one.

As the bug report somewhat mismatches the actual issue, would it be ok to open
proper one, with patch based on the old mailing post above ? If not, then just
ignore the reply and forget it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13575

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.