"Shawn O. Pearce" [off-list ref] writes:
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. As annoying as it may be to explicitly perform the
cast the compiler is right; -1 is not an unsigned value.
Is the compiler really _right_? The usual integral promotion
rules should apply if it claims to be a C compiler, I would
think.
But I think the code actually wants ULONG_MAX there. Is that
symbolic constant available at the point of offending
initialization with the header files we already include, I
wonder.
In other words, how about this patch instead?
-- >8 --
diff --git a/builtin-apply.c b/builtin-apply.c
index db7cdce..aad5526 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -43,7 +43,7 @@ static int apply_verbosely;
static int no_add;
static int show_index_info;
static int line_termination = '\n';
-static unsigned long p_context = -1;
+static unsigned long p_context = ULONG_MAX;
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>] <patch>...";
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. So instead use ULONG_MAX, which is really the
correct constant anyway.
Signed-off-by: Shawn O. Pearce <redacted>
---
This is a resend of my earlier patch in in this same thread...
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index db7cdce..aad5526 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -43,7 +43,7 @@ static int apply_verbosely;
static int no_add;
static int show_index_info;
static int line_termination = '\n';
-static unsigned long p_context = -1;
+static unsigned long p_context = ULONG_MAX;
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>] <patch>...";
--
1.4.3.3.g9621
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. As annoying as it may be to explicitly perform the
cast the compiler is right; -1 is not an unsigned value.
Is the compiler really _right_? The usual integral promotion
rules should apply if it claims to be a C compiler, I would
think.
I'm rusty on my C; but I would expect an error if I tried to assign
a clearly negative value into an unsigned value, especially in a
case like this. It could be compiler is wrong, but as a programmer
I'd want to know I wrote something stupid like that, because maybe
the variable should have been signed. :-)
But I think the code actually wants ULONG_MAX there. Is that
symbolic constant available at the point of offending
initialization with the header files we already include, I
wonder.
Yes, I agree. I almost changed it to ULONG_MAX but didn't since
the original author felt -1 was the better choice here. *shrug*
For what its worth ULONG_MAX works on my Mac OS X system.
Tomorrow when I have access to that "broken" platform again I'll
try ULONG_MAX and see if it compiles there.
--