[PATCH] Support building on GNU/Hurd

[PATCH] Support building on GNU/Hurd

[Thomas Schwinge]

GNU/Hurd systems don't have strlcpy either.

Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
 Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 2fea115..8d9a01b 100644
--- a/Makefile
+++ b/Makefile
@@ -458,6 +458,10 @@ ifeq ($(uname_S),AIX)
 	NO_STRLCPY = YesPlease
 	NEEDS_LIBICONV=YesPlease
 endif
+ifeq ($(uname_S),GNU)
+	# GNU/Hurd
+	NO_STRLCPY=YesPlease
+endif
 ifeq ($(uname_S),IRIX64)
 	NO_IPV6=YesPlease
 	NO_SETENV=YesPlease
-- 
1.5.3.rc3.26.g6c58-dirty

[PATCH] Don't rely on unspecified behavior

[Thomas Schwinge]

Calling access(p, m) with p == NULL is not specified, so don't do that.  On
GNU/Hurd systems doing so will result in an SIGSEGV.

Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
 builtin-add.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-add.c b/builtin-add.c
index 5e6748f..c13c738 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
 	path = git_path("info/exclude");
 	if (!access(path, R_OK))
 		add_excludes_from_file(dir, path);
-	if (!access(excludes_file, R_OK))
+	if (excludes_file != NULL && !access(excludes_file, R_OK))
 		add_excludes_from_file(dir, excludes_file);
 
 	/*
-- 
1.5.3.rc3.26.g6c58-dirty

Re: [PATCH] Don't rely on unspecified behavior

[Thomas Glanzmann]

Hello,

> Calling access(p, m) with p == NULL is not specified, so don't do
> that.  On GNU/Hurd systems doing so will result in an SIGSEGV.

a friend of mine choked on this one when tried git for the second time
(the first time "git-repack -a -d -f" screwed his repository after the
initial checkout. This is fixed for a long time). Lucky me that he had
his libusbdriver in LD_PRELOAD which could not handle the NULL argument.
And I always thought libc would make the check before it does the system
call or does GNU/hurts not use the gnu libc?

	Thomas

Re: [PATCH] Don't rely on unspecified behavior

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Hello!

On Sat, Jul 28, 2007 at 07:39:48PM +0200, Thomas Glanzmann wrote:
> > Calling access(p, m) with p == NULL is not specified, so don't do
> > that.  On GNU/Hurd systems doing so will result in an SIGSEGV.
> 
> a friend of mine choked on this one when tried git for the second time
> (the first time "git-repack -a -d -f" screwed his repository after the
> initial checkout. This is fixed for a long time). Lucky me that he had
> his libusbdriver in LD_PRELOAD which could not handle the NULL argument.
> And I always thought libc would make the check before it does the system
> call or does GNU/hurts not use the gnu libc?

GNU/Hurd systems do (obviously ;-) use the GNU libc.  The glibc
maintainer Roland McGrath explicitly told me that ``access (NULL, m)''
shall not be caught as it is not specified and thus must not be invoked
like this.


I noticed that the patch I sent was prepared for an old version of the
file.  I'll send an updated patch that applies to the current revision.


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[PATCH] Don't rely on unspecified behavior

[Thomas Schwinge]

Calling access(p, m) with p == NULL is not specified, so don't do that.  On
GNU/Hurd systems doing so will result in a SIGSEGV.

Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
 builtin-add.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-add.c b/builtin-add.c
index 7345479..de5c108 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
 		path = git_path("info/exclude");
 		if (!access(path, R_OK))
 			add_excludes_from_file(dir, path);
-		if (!access(excludes_file, R_OK))
+		if (excludes_file != NULL && !access(excludes_file, R_OK))
 			add_excludes_from_file(dir, excludes_file);
 	}
 
-- 
1.5.3.rc3.26.g6c58-dirty

Re: [PATCH] Don't rely on unspecified behavior

[Johannes Schindelin]

Hi,

On Sat, 28 Jul 2007, Thomas Schwinge wrote:

> Calling access(p, m) with p == NULL is not specified, so don't do that.  On
> GNU/Hurd systems doing so will result in a SIGSEGV.
> 
> Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> ---

Isn't this the same patch as you sent before?

>  builtin-add.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/builtin-add.c b/builtin-add.c
> index 7345479..de5c108 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
>  		path = git_path("info/exclude");
>  		if (!access(path, R_OK))
>  			add_excludes_from_file(dir, path);
> -		if (!access(excludes_file, R_OK))
> +		if (excludes_file != NULL && !access(excludes_file, R_OK))

We usually omit the "!= NULL"; see the other source code in git.git.

Ciao,
Dscho

Re: [PATCH] Don't rely on unspecified behavior

[Thomas Glanzmann]

Hello Dscho,

> Isn't this the same patch as you sent before?

> > @@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
> > @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
       ~~~~~ ~~~~~                                                                            ~

The offset of the diff has changed. Not that git couldn't sort it out by
itself. And the function had one or more parameters less.

	Thomas

Re: [PATCH] Don't rely on unspecified behavior

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Hello!

On Sat, Jul 28, 2007 at 08:30:07PM +0100, Johannes Schindelin wrote:
> On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> > Calling access(p, m) with p == NULL is not specified, so don't do that.  On
> > GNU/Hurd systems doing so will result in a SIGSEGV.
> > 
> > Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> > ---
> 
> Isn't this the same patch as you sent before?

As I wrote in <20070728182542.GA22651@fencepost.gnu.org>: ``I noticed
that the patch I sent was prepared for an old version of the file.  I'll
send an updated patch that applies to the current revision.''

> > +		if (excludes_file != NULL && !access(excludes_file, R_OK))
> 
> We usually omit the "!= NULL"; see the other source code in git.git.

Okay, so I should sent a thusly modified version to get it applied?


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH] Don't rely on unspecified behavior

[Johannes Schindelin]

Hi,

On Sat, 28 Jul 2007, Thomas Glanzmann wrote:

> > Isn't this the same patch as you sent before?
> 
> > > @@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
> > > @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
>        ~~~~~ ~~~~~                                                                            ~
> 
> The offset of the diff has changed. Not that git couldn't sort it out by
> itself. And the function had one or more parameters less.

Ah.  Thanks for the explanation.

Ciao,
Dscho

Re: [PATCH] Don't rely on unspecified behavior

[Johannes Schindelin]

Hi,

On Sat, 28 Jul 2007, Thomas Schwinge wrote:

> On Sat, Jul 28, 2007 at 08:30:07PM +0100, Johannes Schindelin wrote:
> > On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> > > Calling access(p, m) with p == NULL is not specified, so don't do that.  On
> > > GNU/Hurd systems doing so will result in a SIGSEGV.
> > > 
> > > Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> > > ---
> > 
> > Isn't this the same patch as you sent before?
> 
> As I wrote in <20070728182542.GA22651@fencepost.gnu.org>: ``I noticed
> that the patch I sent was prepared for an old version of the file.  I'll
> send an updated patch that applies to the current revision.''

Ah.

> > > +		if (excludes_file != NULL && !access(excludes_file, R_OK))
> > 
> > We usually omit the "!= NULL"; see the other source code in git.git.
> 
> Okay, so I should sent a thusly modified version to get it applied?

I don't think that is necessary; a small change like this is usually fixed 
by Junio with --amend.

Ciao,
Dscho

Re: [PATCH] Don't rely on unspecified behavior

[Thomas Glanzmann]

Hello,

> Ah.  Thanks for the explanation.

I have operating system / real time systems exam on monday. I have to
prepare myself in stating the obvious.

	Thomas