Re: [RFC] Support for HP NonStop

"Joachim Schmitz" [off-list ref] writes:

Yeah, it appears that glibc headers have strcasecmp() and friends in
the <string.h> and that was why majority of us were fine without
including <strings.h>.  A cursory look of /usr/include/strings.h on
a GNU system suggests that it is safe to include <strings.h> after
we incude <string.h> on that platform.

I think it is OK to leave it "__TANDEM /* or HAVE_STRINGS_H? */" for
now and let the next person who wants to port us to a platform that
needs this inclusion turn it to HAVE_STRINGS_H.  Alternatively, we
bite the bullet now and include <strings.h> on any platform that has
the header file and see if anybody complains (that reminds me; I at
least should get one flavor of BSD build environment for this kind
of thing myself).

A bit wider context for this hunk is

	#ifndef NO_INTTYPES_H
        #include <inttypes.h>
        #else
        #include <stdint.h>
	#endif

So we have been assuming that <stdint.h> has intptr_t but __TANDEM
apparently doesn't.  POSIX requires intptr_t and uintptr_t to be
declared for systems conforming to XSI, but otherwise these are
optional (in other words, some XSI non-conforming platforms may have
them in <stdint.h>), so it would not help to check _XOPEN_UNIX to
see if the system is XSI X-<.  We would need NO_INTPTR_T as you
hinted above, perhaps like this.

	#ifndef NO_INTTYPES_H
        #include <inttypes.h>
        #else
        #include <stdint.h>
	#endif
	#ifdef NO_INTPTR_T
        typedef int intptr_t;
        typedef unsigned int uintptr_t;
	#endif

By the way, is "int" wide enough, or should they be "long"?

From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Friday, August 24, 2012 10:13 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [RFC] Support for HP NonStop

"Joachim Schmitz" [off-list ref] writes:

quoted

Hi folks

On top of the patches I’ve submitted so far, which were needed for HP NonStop,
but possibly useful for other platforms too, here is one that is at least in parts NonStop specific

diff --git a/git-compat-util.h b/git-compat-util.h
index a047221..d6a142a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h

@@ -74,7 +74,8 @@

# define _XOPEN_SOURCE 500
# endif
#elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && \
-      !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__)
+      !defined(_M_UNIX) && !defined(__sgi) && !defined(__DragonFly__) && \
+      !defined(__TANDEM)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 fo
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
+#ifdef __TANDEM /* or HAVE_STRINGS_H ? */
+#include <strings.h> /* for strcasecmp() */
+#endif
#include <errno.h>
#include <limits.h>
#include <sys/param.h>

Yeah, it appears that glibc headers have strcasecmp() and friends in
the <string.h> and that was why majority of us were fine without
including <strings.h>.  A cursory look of /usr/include/strings.h on
a GNU system suggests that it is safe to include <strings.h> after
we incude <string.h> on that platform.

I think it is OK to leave it "__TANDEM /* or HAVE_STRINGS_H? */" for
now and let the next person who wants to port us to a platform that
needs this inclusion turn it to HAVE_STRINGS_H.  Alternatively, we
bite the bullet now and include <strings.h> on any platform that has
the header file and see if anybody complains

That's exaclty why I'm asking here ;-), seems a decision needs to be made.
How would one differentiate platrots that have strings.h from those that don't?
Guess it wont'f work without some ifdef. But it could be NO_STRINGS_H and 
force the platforms that don't have to update this in Makefile?

Reminds me of a related issue: in compat/fnmatch/fnmatch.c there is this:
#if HAVE_STRING_H || defined _LIBC
# include <string.h>
#else
# include <strings.h>
#endif

There's no place where HAVE_STRING_H get set
This looks wrong to me, as here, at least for NonStop, I have to takes measure in Makefile, 
because there's no other place where HAVE_STRING_H ever gets set:
       COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c

Do platforms exist without string.h?
Maybe fnmatch.c should look like this instead?
#if HAVE_STRING_H || defined _LIBC
# include <string.h>
#endif
# ifndef NO_STRINGS_H
# include <strings.h>
#endif

(that reminds me; I at
least should get one flavor of BSD build environment for this kind
of thing myself).

quoted

@@ -141,6 +145,10 @@

#else
#include <stdint.h>
#endif
+#ifdef __TANDEM /* or NO_INTPTR_T resp. NO_UINTPTR_T? */
+typedef int intptr_t;
+typedef unsigned int uintptr_t;
+#endif

A bit wider context for this hunk is

	#ifndef NO_INTTYPES_H
        #include <inttypes.h>
        #else
        #include <stdint.h>
	#endif

So we have been assuming that <stdint.h> has intptr_t but __TANDEM
apparently doesn't. 

Exactly. Our stdint.h says:
/*
 *  Special integer types (optional types intptr_t/uintptr_t not defined)
 */

This may change in the future though. One reason why __TANDEM might not be the best check :-)

POSIX requires intptr_t and uintptr_t to be
declared for systems conforming to XSI, but otherwise these are
optional (in other words, some XSI non-conforming platforms may have
them in <stdint.h>), so it would not help to check _XOPEN_UNIX to
see if the system is XSI X-<.  We would need NO_INTPTR_T as you
hinted above, perhaps like this.

	#ifndef NO_INTTYPES_H
        #include <inttypes.h>
        #else
        #include <stdint.h>
	#endif
	#ifdef NO_INTPTR_T
        typedef int intptr_t;
        typedef unsigned int uintptr_t;
	#endif

NO_INTPTR_T for both types?
OK by me.
If need be an NOUINTPTR could get added later, I guess

By the way, is "int" wide enough, or should they be "long"?

int and long have the same size, 32-bit, here on NonStop.
But we do have 64-bit types too. Not sure which to take though.

Bye, Jojo

On Friday 2012-08-24 22:43, Joachim Schmitz wrote:

quoted

By the way, is "int" wide enough [for intptr_t/uintptr_t],
or should they be "long"?

int and long have the same size, 32-bit, here on NonStop.
But we do have 64-bit types too. Not sure which to take though.

intptr_t is supposed to hold a void * pointer, so should be
at least as big.

From: Jan Engelhardt [mailto:jengelh@inai.de]
Sent: Wednesday, September 19, 2012 9:24 AM
To: Joachim Schmitz
Cc: 'Junio C Hamano'; git@vger.kernel.org
Subject: RE: [RFC] Support for HP NonStop


On Friday 2012-08-24 22:43, Joachim Schmitz wrote:

quoted

quoted

By the way, is "int" wide enough [for intptr_t/uintptr_t],
or should they be "long"?

int and long have the same size, 32-bit, here on NonStop.
But we do have 64-bit types too. Not sure which to take though.

intptr_t is supposed to hold a void * pointer, so should be
at least as big.

OK, thanks. We are on IA64 but still use the ILP32 model (so 32bit pointers. Support for LP64 has been added recently, but isn't the
default.
However, long changes from 32bit to 64 bit when changing from ILP32 to LP64, so is the save bet here, right?