From: "Joachim Schmitz" <jojo@schmitz-digital.de>
To: "'Junio C Hamano'" <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: RE: [RFC] Support for HP NonStop
Date: Sat, 25 Aug 2012 10:03:23 +0200 [thread overview]
Message-ID: <000f01cd8298$19988c00$4cc9a400$@schmitz-digital.de> (raw)
In-Reply-To: <7vvcg8x8lo.fsf@alter.siamese.dyndns.org>
> From: Junio C Hamano [mailto:gitster@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" <jojo@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 K&C 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
next prev parent reply other threads:[~2012-08-25 8:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 19:22 [RFC] Support for HP NonStop Joachim Schmitz
2012-08-24 20:12 ` Junio C Hamano
2012-08-24 20:43 ` Joachim Schmitz
2012-08-24 21:50 ` Junio C Hamano
2012-08-25 8:03 ` Joachim Schmitz [this message]
2012-09-19 7:24 ` Jan Engelhardt
2012-09-19 8:16 ` Joachim Schmitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000f01cd8298$19988c00$4cc9a400$@schmitz-digital.de' \
--to=jojo@schmitz-digital.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).