RE: [RFC] Support for HP NonStop
On Friday 2012-08-24 22:43, Joachim Schmitz wrote: 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Support for HP NonStop
From: Jan Engelhardt [mailto:jeng...@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: 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Support for HP NonStop
From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, August 24, 2012 11:51 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [RFC] Support for HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: 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,... This is because it is a borrowed file from glibc, and we try to minimize changes to such a file. If you need HAVE_STRING_H to force inclusion of string.h on your platform, doing this: COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c is perfectly the right thing to do. It should be set by default and those that don't have it, should (have to) disable it. In Makefile: ifndef NO_STRING_H COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c endif Do platforms exist without string.h? Maybe fnmatch.c should look like this instead? We try to minimize changes to such a file we borrow from upstream; Valid point, but... especially we do not do so lightly when we have to ask do platforms exist? Of course, they do---otherwise glibc folks wouldn't have written such a conditional. Hmm, well, why then doesn't git-compat.util.h use the same mechanism? (and no ,it should not!) I guess because as of now nobody ever tried to port git to a platform that doesn't have string.h. string.h is C89 ANSI/ISO standard (and was part of even the earliest KC C), in place since more than 22 years now! It may not be available on embedded platforms, but those won't be able to run git anyway I'd guess. Newer version of gnulib's fnmatch.c don't use this anymore, git's is from 99, according to the Copyright: Copyright (C) 1991, 92, 93, 96, 97, 98, 99 The current gnulib one shows: Copyright (C) 1991-1993, 1996-2007, 2009-2012 Time to upgrade, if you'd ask me... Same may go for poll.c BTW Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for HP NonStop
Joachim Schmitz j...@schmitz-digital.de 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 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. 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes: 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,... This is because it is a borrowed file from glibc, and we try to minimize changes to such a file. If you need HAVE_STRING_H to force inclusion of string.h on your platform, doing this: COMPAT_CFLAGS += -DHAVE_STRING_H=1 # needed in compat/fnmatch/fnmatch.c is perfectly the right thing to do. Do platforms exist without string.h? Maybe fnmatch.c should look like this instead? We try to minimize changes to such a file we borrow from upstream; especially we do not do so lightly when we have to ask do platforms exist? Of course, they do---otherwise glibc folks wouldn't have written such a conditional. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
