This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #6 from Michal Soltys <soltys at ziu dot info> ---
Hi,

Damn it's been a while since I reported it, almost forgot it as well.

My original report is terribly worded - I tried to give example of situation
when it easily "bugs", but then the whole report kind of went off the track.

Anyway, long time ago there was a bug in glibc related to 64bit architectures,
where SSIZE_MAX unconditionally expanded to INT_MAX (of type 'int') while at
the same time ssize_t was 'long int'. This was blatantly wrong for 64bit arches
and in that case we actually had 64bit type and 32bit value defining possible
limit.

The correct resolution I think was proposed in:

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

But then they just decided to unconditionally set it to LONG_MAX - which kind
of reversed the bug with minor difference - it wasn't damaging in 32bit as both
the type and the value (of different type) were 32bit in the end.

The current situation is:

ssize_t -> __SSIZE_T_TYPE -> __SWORD_TYPE

__SWORD_TYPE is either:

if __WORDSIZE is 32: int
if __WORDSIZE is 64: long int

for those types, proper maximum values are respectively INT_MAX and LONG_MAX -
the latter having explicit 'L' - thus type 'long int' - and obviously different
value for 32bit and 64bit cases (LLP64 model iirc).

At the same time value of SSIZE_MAX is just LONG_MAX - explicitly defined as a
value of type 'long int' - it /formally/ doesn't fit into type 'int'.
2147483647 (INT_MAX) would be correct, 2147483647L (LONG_MAX) isn't. This is
also the reason (see my original report) why gcc emited warning. %zd (see glibc
manual) is of type ssize_t (int). SSIZE_MAX (LONG_MAX) is explicitly of type
long int. It's the same kind of warning that would happen if we did
printf("%d\n", 1L); (while compiling with -Wformat, asking gcc to keep an eye
on what we do in our printfs.).

Something like

#ifndef SSIZE_MAX
# include <bits/wordsize.h>
# if __WORDSIZE == 64
#  define SSIZE_MAX     LONG_MAX
# else
#  define SSIZE_MAX     INT_MAX
# endif
#endif

instead of:

#ifndef SSIZE_MAX
# define SSIZE_MAX      LONG_MAX
#endif

in posix/bits/posix1_lim.h would correct the situation (see Jes Sorensen's
mail).

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]