"Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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>..."; - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html