> From: Junio C Hamano [mailto:[email protected]]
> Sent: Friday, August 24, 2012 10:13 PM
> To: Joachim Schmitz
> Cc: [email protected]
> Subject: Re: [RFC] Support for HP NonStop
>
> "Joachim Schmitz" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
