threads / patch / 39870

patchFix detection of uname failure

Subject: [PATCH] Fix detection of uname failure

## tl;dr

8 messages between Jul 17, 2015 and Jul 18, 2015. Diffs are folded; open one to read it.

replies: 7people: 3as markdown or json

Charles Bailey· Jul 17, 2015, 12:11 UTC · lore
From: Charles Bailey <cbailey32@bloomberg.net>

According to POSIX specification uname must return -1 on failure and a non-negative value on success. Although many implementations do return 0 on success it is valid to return any positive value for success. In particular, Solaris returns 1.

Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
---
 dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to dir.c +1 −1
diff --git a/dir.c b/dir.c
index 8209f8b..52dbfd0 100644
--- a/dir.c
+++ b/dir.c
@@ -1848,7 +1848,7 @@ static const char *get_ident_string(void)
 
 	if (sb.len)
 		return sb.buf;
-	if (uname(&uts))
+	if (uname(&uts) == -1)
 		die_errno(_("failed to get kernel name and information"));
 	strbuf_addf(&sb, "Location %s, system %s %s %s", get_git_work_tree(),
 		    uts.sysname, uts.release, uts.version);
-- 
2.4.0.53.g8440f74
Johannes Schindelin· Jul 17, 2015, 13:06 UTC · re: Charles Bailey · lore

Re: [PATCH] Fix detection of uname failure

Hi Charles,
On 2015-07-17 14:11, Charles Bailey wrote:
Show 10 quoted lines
> diff --git a/dir.c b/dir.c
> index 8209f8b..52dbfd0 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1848,7 +1848,7 @@ static const char *get_ident_string(void)
>  
>  	if (sb.len)
>  		return sb.buf;
> -	if (uname(&uts))
> +	if (uname(&uts) == -1)
>From a quick `git grep '== -1'` and another quick `git grep '< 0'` it appears to me that we prefer the latter. Maybe you want to adjust it in the patch, too?

Ciao, Johannes

Charles Bailey· Jul 17, 2015, 17:01 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Fix detection of uname failure

On Fri, Jul 17, 2015 at 03:06:57PM +0200, Johannes Schindelin wrote:
> 
> From a quick `git grep '== -1'` and another quick `git grep '< 0'` it appears to me that we prefer the latter. Maybe you want to adjust it in the patch, too?

I did the same grep and found lots of examples of both. Many of the "< 0" applied to comparisons with variables and not API calls and many were internal (to git) calls and not POSIX or C library calls so I wasn't convinced to change my initial fix.

Having said that and thought about it some more, I think '< 0' is probably better. In POSIX, we shouldn't ever get a negative value which isn't -1, but if we ever do it is probably safer to fail. I'll send and update.

Charles.
Junio C Hamano· Jul 17, 2015, 17:09 UTC · re: Charles Bailey · lore

Re: [PATCH] Fix detection of uname failure

Charles Bailey <charles@hashpling.org> writes:
> ... I think '< 0' is
> probably better. In POSIX, we shouldn't ever get a negative value which
> isn't -1, but if we ever do it is probably safer to fail. I'll send and
> update.
Thanks; I was about to type the same reasoning and conclusion ;-)
Charles Bailey· Jul 17, 2015, 17:09 UTC · re: Johannes Schindelin · lore

[PATCH v2] Fix detection of uname failure

From: Charles Bailey <cbailey32@bloomberg.net>

According to POSIX specification uname must return -1 on failure and a non-negative value on success. Although many implementations do return 0 on success it is valid to return any positive value for success. In particular, Solaris returns 1.

Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
---
 dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to dir.c +1 −1
diff --git a/dir.c b/dir.c
index 8209f8b..1d42811 100644
--- a/dir.c
+++ b/dir.c
@@ -1848,7 +1848,7 @@ static const char *get_ident_string(void)
 
 	if (sb.len)
 		return sb.buf;
-	if (uname(&uts))
+	if (uname(&uts) < 0)
 		die_errno(_("failed to get kernel name and information"));
 	strbuf_addf(&sb, "Location %s, system %s %s %s", get_git_work_tree(),
 		    uts.sysname, uts.release, uts.version);
-- 
2.4.0.53.g8440f74
Johannes Schindelin· Jul 17, 2015, 21:07 UTC · re: Charles Bailey · lore

Re: [PATCH v2] Fix detection of uname failure

On 2015-07-17 19:09, Charles Bailey wrote:
Show 8 quoted lines
> From: Charles Bailey <cbailey32@bloomberg.net>
> 
> According to POSIX specification uname must return -1 on failure and a
> non-negative value on success. Although many implementations do return 0
> on success it is valid to return any positive value for success.  In
> particular, Solaris returns 1.
> 
> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Junio C Hamano· Jul 17, 2015, 21:39 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Fix detection of uname failure

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 11 quoted lines
> On 2015-07-17 19:09, Charles Bailey wrote:
>> From: Charles Bailey <cbailey32@bloomberg.net>
>> 
>> According to POSIX specification uname must return -1 on failure and a
>> non-negative value on success. Although many implementations do return 0
>> on success it is valid to return any positive value for success.  In
>> particular, Solaris returns 1.
>> 
>> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>

I'd s/Ack/Review/; as the original is not your code but you are well qualified (and have my trust) to judge the change to this codepath ;-)

Thanks.
Johannes Schindelin· Jul 18, 2015, 06:58 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Fix detection of uname failure

Hi Junio,
On 2015-07-17 23:39, Junio C Hamano wrote:
Show 17 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
>> On 2015-07-17 19:09, Charles Bailey wrote:
>>> From: Charles Bailey <cbailey32@bloomberg.net>
>>>
>>> According to POSIX specification uname must return -1 on failure and a
>>> non-negative value on success. Although many implementations do return 0
>>> on success it is valid to return any positive value for success.  In
>>> particular, Solaris returns 1.
>>>
>>> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
>>
>> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> I'd s/Ack/Review/; as the original is not your code but you are well
> qualified (and have my trust) to judge the change to this codepath
> ;-)
Yeah, that's what I meant ;-)

Ciao, Dscho

← back to recent threads