This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64
- From: "soltys at ziu dot info" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 12 Jul 2016 21:46:15 +0000
- Subject: [Bug libc/13575] SSIZE_MAX defined as LONG_MAX is inconsistent with SIZE_MAX, when __WORDSIZE != 64
- Auto-submitted: auto-generated
- References: <bug-13575-131@http.sourceware.org/bugzilla/>
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.