> From: Junio C Hamano [mailto:gitster@xxxxxxxxx] > Sent: Friday, August 24, 2012 10:13 PM > To: Joachim Schmitz > Cc: git@xxxxxxxxxxxxxxx > Subject: Re: [RFC] Support for HP NonStop > > "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: > > > 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). > > > @@ -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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html