Re: SSIZE_MAX on ia64

Re: SSIZE_MAX on ia64

[Roland McGrath]

> But it seems to me like it might be sensible to have the compiler spit
> out these declarations at install time, since they are really
> compiler-dependent facts, right?

No, ssize_t is a typedef defined by libc headers.  It is not used in any
interfaces the compiler knows about (unlike size_t and ptrdiff_t, for example).

Re: SSIZE_MAX on ia64

[Ulrich Drepper]

Roland McGrath wrote:
> I just changed it to LONG_MAX unconditionally, since that works fine on all
> the platforms we have now.  It's still possible for a system-specific
> bits/local_lim.h file to override if it such a need arises.

Yep, that's fine.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: SSIZE_MAX on ia64

[Roland McGrath]

> However, shouldn't this be considered a candidate for 2.2 as well?

Yes, it's incorrect as it stands on 64-bit platforms.
I will put the change into the other branch too.

Re: SSIZE_MAX on ia64

[Jes Sorensen]

>>>>> "Roland" == Roland McGrath <roland@frob.com> writes:

Roland> I just changed it to LONG_MAX unconditionally, since that
Roland> works fine on all the platforms we have now.  It's still
Roland> possible for a system-specific bits/local_lim.h file to
Roland> override if it such a need arises.

Thanks, you're right. Not sure what I was thinking.

However, shouldn't this be considered a candidate for 2.2 as well?

Thanks,
Jes

Re: SSIZE_MAX on ia64

[Roland McGrath]

I just changed it to LONG_MAX unconditionally, since that works fine on all
the platforms we have now.  It's still possible for a system-specific
bits/local_lim.h file to override if it such a need arises.

Re: SSIZE_MAX on ia64

[Jes Sorensen]

>>>>> "Roland" == Roland McGrath <roland@frob.com> writes:

Roland> SSIZE_MAX must accurately reflect the ssize_t type.  It is
Roland> presently incorrect on all 64-bit platforms.  On every
Roland> platform I am aware of, ssize_t == long int (i.e. 32 bits
Roland> where long is 32 and 64 bits where long is 64).  So it would
Roland> not hurt to generically use LONG_MAX, and that would be
Roland> simpler.  I think it is a valid assumption at the moment that
Roland> long == wordsize.  If not, we could also have SSIZE_MAX
Roland> defined conditional on __WORDSIZE, which is still simpler than
Roland> adding a specific definition for particular platforms.

Hi Roland

That sounds good to me, what about the following patch then? The good
thing is that this way we still allow an architecture to override it
if necessary.

Jes

2002-08-02  Jes Sorensen  <jes@trained-monkey.org>

	* posix/bits/posix1_lim.h: #define SSIZE_MAX based on the
	definition of __WORDSIZE.

--- posix/bits/posix1_lim.h~	Mon Jul  9 19:18:00 2001
+++ posix/bits/posix1_lim.h	Fri Aug  2 18:57:24 2002
@@ -127,8 +127,13 @@
 
 
 #ifndef	SSIZE_MAX
+#include <bits/wordsize.h>
+#if __WORDSIZE == 64
+# define SSIZE_MAX	LONG_MAX
+#else
 # define SSIZE_MAX	INT_MAX
 #endif
+#endif
 
 
 /* This value is a guaranteed minimum maximum.

Re: SSIZE_MAX on ia64

[Roland McGrath]

SSIZE_MAX must accurately reflect the ssize_t type.  It is presently
incorrect on all 64-bit platforms.  On every platform I am aware of,
ssize_t == long int (i.e. 32 bits where long is 32 and 64 bits where long
is 64).  So it would not hurt to generically use LONG_MAX, and that would
be simpler.  I think it is a valid assumption at the moment that long ==
wordsize.  If not, we could also have SSIZE_MAX defined conditional on
__WORDSIZE, which is still simpler than adding a specific definition for
particular platforms.

SSIZE_MAX on ia64

[Jes Sorensen]

Hi

(ARGH try again with the right From: address)

I received a report from Chris Yeoh that glibc/ia64 defines SSIZE_MAX to
MAX_INT while we define ssize_t as an int64.

I see posix/bits/posix1_lim.h defines SSIZE_MAX as INT_MAX and include
sysdeps/unix/sysv/linux/ia64/bits/types.h declares __ssize_t as
__int64_t.

Question here, if _POSIX_SSIZE_MAX is 32767 should we bother upping
SSIZE_MAX to LONG_MAX? If we should do this, then I suggest the attached
patch which creates a sysdeps/unix/sysv/linux/ia64/bits/local_lim.h
which includes the SSIZE_MAX declaration.

Comments?

Cheers,
Jes

2002-08-02  Jes Sorensen  <jes@trained-monkey.org>

	* sysdeps/unix/sysv/linux/ia64/bits/local_lim.h: New file copied
	from sysdeps/unix/sysv/linux/bits/local_lim.h with the addition of
	SSIZE_MAX defined to LONG_MAX

--- /dev/null	Wed Aug 16 12:34:44 2000
+++ sysdeps/unix/sysv/linux/ia64/bits/local_lim.h	Fri Aug  2 18:36:25 2002
@@ -0,0 +1,59 @@
+/* Minimum guaranteed maximum values for system limits.  Linux version.
+   Copyright (C) 1993-1998, 2000, 2002 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+/* The kernel header pollutes the namespace with the NR_OPEN symbol
+   and defines LINK_MAX although filesystems have different maxima.  A
+   similar thing is true for OPEN_MAX: the limit can be changed at
+   runtime and therefore the macro must not be defined.  Remove this
+   after including the header if necessary.  */
+#ifndef NR_OPEN
+# define __undef_NR_OPEN
+#endif
+#ifndef LINK_MAX
+# define __undef_LINK_MAX
+#endif
+#ifndef OPEN_MAX
+# define __undef_OPEN_MAX
+#endif
+
+/* The kernel sources contain a file with all the needed information.  */
+#include <linux/limits.h>
+
+/* Have to remove NR_OPEN?  */
+#ifdef __undef_NR_OPEN
+# undef NR_OPEN
+# undef __undef_NR_OPEN
+#endif
+/* Have to remove LINK_MAX?  */
+#ifdef __undef_LINK_MAX
+# undef LINK_MAX
+# undef __undef_LINK_MAX
+#endif
+/* Have to remove OPEN_MAX?  */
+#ifdef __undef_OPEN_MAX
+# undef OPEN_MAX
+# undef __undef_OPEN_MAX
+#endif
+
+/* Maximum amount by which a process can descrease its asynchronous I/O
+   priority level.  */
+#define AIO_PRIO_DELTA_MAX	20
+
+/* Define SSIZE_MAX to match the type in types.h. */
+#define SSIZE_MAX		LONG_MAX