Remove more gcc extension usage.

Removing these last remaining extension uses allows GIT to compile with the Sun C compiler rather then gcc. This can be handy when you are trying to compile GIT on a Solaris system that seems to have a total lack of GNU utilities.

---
 builtin-read-tree.c |   18 ++++++++----------
 checkout-index.c    |   10 ++--------
 diff.c              |   12 ++++++------
 3 files changed, 16 insertions(+), 24 deletions(-)

index 9a2099d..33b2faf 100644
@@ -43,10 +43,7 @@ struct tree_entry_list {
 	const unsigned char *sha1;
 };
 
-static struct tree_entry_list df_conflict_list = {
-	.name = NULL,
-	.next = &df_conflict_list
-};
+static struct tree_entry_list df_conflict_list;
 
 typedef int (*merge_fn_t)(struct cache_entry **src);
 

@@ -333,14 +330,9 @@ static void setup_progress_signal(void)
 	setitimer(ITIMER_REAL, &v, NULL);
 }
 
+static struct checkout state;
 static void check_updates(struct cache_entry **src, int nr)
 {
-	static struct checkout state = {
-		.base_dir = "",
-		.force = 1,
-		.quiet = 1,
-		.refresh_cache = 1,
-	};
 	unsigned short mask = htons(CE_UPDATE);
 	unsigned last_percent = 200, cnt = 0, total = 0;
 

@@ -884,6 +876,12 @@ int cmd_read_tree(int argc, const char *
 	unsigned char sha1[20];
 	merge_fn_t fn = NULL;
 
+	df_conflict_list.next = &df_conflict_list;
+	state.base_dir = "";
+	state.force = 1;
+	state.quiet = 1;
+	state.refresh_cache = 1;
+
 	setup_git_directory();
 	git_config(git_default_config);
 

index ea40bc2..88c21cb 100644
@@ -49,14 +49,7 @@ static int checkout_stage; /* default to
 static int to_tempfile;
 static char topath[4][MAXPATHLEN+1];
 
-static struct checkout state = {
-	.base_dir = "",
-	.base_dir_len = 0,
-	.force = 0,
-	.quiet = 0,
-	.not_new = 0,
-	.refresh_cache = 0,
-};
+static struct checkout state;
 
 static void write_tempfile_record (const char *name)
 {

@@ -177,6 +170,7 @@ int main(int argc, char **argv)
 	int all = 0;
 	int read_from_stdin = 0;
 
+	state.base_dir = "";
 	prefix = setup_git_directory();
 	git_config(git_default_config);
 	prefix_length = prefix ? strlen(prefix) : 0;

index f0450a8..4b389b1 100644
@@ -43,12 +43,12 @@ #define COLOR_CYAN    "\033[36m"
 #define COLOR_WHITE   "\033[37m"
 
 static const char *diff_colors[] = {
-	[DIFF_RESET]    = COLOR_RESET,
-	[DIFF_PLAIN]    = COLOR_NORMAL,
-	[DIFF_METAINFO] = COLOR_BOLD,
-	[DIFF_FRAGINFO] = COLOR_CYAN,
-	[DIFF_FILE_OLD] = COLOR_RED,
-	[DIFF_FILE_NEW] = COLOR_GREEN,
+	COLOR_RESET,
+	COLOR_NORMAL,
+	COLOR_BOLD,
+	COLOR_CYAN,
+	COLOR_RED,
+	COLOR_GREEN
 };
 
 static int parse_diff_color_slot(const char *var, int ofs)

1.4.1.gbcf1

Two points.

- Aren't the constructs you ripped out not GCC extension, rather proper ISO C99?

- Our Makefile is pretty GNU already. I think people have pointed out and ripped out bashisms from our shell scripts, but I would not be surprised if the default Sun /bin/sh does not understand POSIXy features some of them use.

Hmm. I'm not sure actually. I don't do much C hacking these days so I haven't kept current with what C99 has and doesn't. I just know that these small changes made the core plumbing build and run fine on Solaris with only GNU make being present. I didn't even attempt to use the higher level Poreclainish shell script commands.

Monday I'll look to see if there's an option that can be given to the Solaris compiler to make it accept these constructs. Maybe a simple CFLAGS change in my config.mak would resolve what this patch was trying to do.

I realize that. Asking someone to compile GNU make in their home directory before they build GIT to their home directory isn't a big deal (took me all of 30 seconds to download the latest and ./configure&&make install it). Asking someone to download and compile binutils and gcc because their local site manager won't install them for you is another matter entirely...

Shawn.

Yes, that's valid C99. So Sun ships a compiler conforming to old standards only, or which is configured to do so.

Thanks.

AFAIK, relying on the '#!/bin/sh' thing is, from the POSIX point of view, just plain wrong. IIRC, the '#!' thing even doesn't need to be implemented! POSIX tells you to call scripts with their interpreters, for a reason. /bin/sh needn't be POSIX compliant, but the first shell found in the $PATH has to. So for what it's worth, shell scripts should be called like sh foo.sh', and if we narrow to expect the #!' to work, we'd better call it like #!/usr/bin/env sh' to get the $PATH sh' and not /bin/sh .

MfG, JBG

Jan-Benedict Glaw       [email protected]    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

So Monday turned out to be today. The compiler version:

  $ cc -V                                                        
  cc: Forte Developer 7 C 5.4 2002/03/09
  usage: cc [ options] files.  Use 'cc -flags' for details

and from man cc:

-xc99 enables C99 features:

The following is a list of the implemented features of the ISO/IEC 9899:1999, Programming Language - C stan- dard. See the C User's Guide for a detailed explanation of the compiler's support for these featuers:

o Idempotent Qualifiers
o _Pragma
o Mixed Declarations and Code
o static and Other Type Qualifiers Allowed in Array Declarators
o Flexible Array Members
o Declarations Using Implicit int
o Disallowed Implicit int and Implicit Function Declarations
o Declaration in for-Loop Statement
o C99 Keywords
o __func__ Support
o Macros With A Variable Number of Arguments
o Variable Length Arrays
o inline Specifier For Static Functions
o Commenting Code with //

So neither of the constructs my patch removes are supported in this (old) compiler, although a newer one might accept them with -xc99. Yes, I tried building a pristine git-1.4.1 with -xc99. It barfed, as one would expect given the description above.

Since we don't have a newer version of cc available (not sure why) I'm stuck with needing to make the code changes in my patch just to get GIT to compile.

Shawn.

Hi, Shawn!

[skip]

This must be enabled already because it's used in git (see FLEX_ARRAY).

This means that the Sun compiler has almost all c99 features used by git with just a little exception (initializers). I think it's fair that we fix this incompatibility. It's very very minor compared to what "gcc -std=c89 -pedantic" would have required.

Regards,
Pavel Roskin

^^^^^^^^

You're kidding, aren't you?

MfG, JBG

Jan-Benedict Glaw       [email protected]    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

In fact I can build git with this command:

make CFLAGS="-std=c89 -pedantic -Dinline=__inline -D_GNU_SOURCE"

if I fix all C++ comments. It warns a lot about "flexible array members" and other violations, but the resulting executable passes the test. That's Fedora Core 5 with gcc 4.1.1.

What I meant it that if we go all the way to strict c89 (even with a modern libc) and fix all the warnings, it will be much more than what is needed to support Sun's C compiler with its partial c99 support.

We can satisfy the Sun's compiler and yet retain flexible arrays and other c99 goodies.

Maybe I'm missing your point (or you joke).

Regards,
Pavel Roskin

[...]

Why should we jump through the hoops to support an obsolete standard because proprietary compilers don't stand today's standards?

MfG, JBG

Jan-Benedict Glaw       [email protected]    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Quoting Jan-Benedict Glaw <[email protected]>:

Because we want git to run on such systems, and asking to compile gcc first is too much to ask for.

There are still missing or broken C99 features in the current gcc:
http://gcc.gnu.org/c99status.html

Why do we want to avoid C99 features broken in gcc? Because we want users to be able to compile git with today's gcc, and installing a different compiler (proprietary or even free) to compile git is too much to ask for.

Maybe if cvsup compiled with gcc, we would be using cvsup backend for git now. Or maybe cvsup would develop to take the niche currently occupied by git. But cvsup was written in Modula 3, perhaps a superior language compared to C. You would have to compile a Modula 3 compiler and a Modula 3 library just to be able to compile cvsup. The necessary software was free, but compiling it was not trivial. Let's see, where is cvsup now? How popular is it?

After all, it's a trade-off between ease of coding and ease of installing. Make coding too hard, and the developers will go elsewhere. Make installation too hard, and the project starts losing users. And who wants to contribute to an unpopular project?

Going all the way to strict c89 could be too much, but fixing initializers in a few places is a minor issue. Users of the Sun's compiler can expect us to do such changes, just like users of gcc would ask to fix a program that uses c99 features not yet available in gcc.

--
Regards,
Pavel Roskin

As I said, there are precompiled binaries for basically all useable systems out there.

Sure. As are in other compilers. But you forgot to mention that these missing or broken features are mostly of no use to commonly used C code. So that's a non-issue. (If it was a real issue, you can be sure that I'd drop a ton of bug reports into GCC's Bugzilla...)

I'm not sure about specifically the initializers thing. Personally, I consider the new C99 initializers one of the very best things that ever happened to the C language, because it fixes a _real_ problem. You may have noticed that eg. for the kernel code, these are used throughoutly...

MfG, JBG

Jan-Benedict Glaw       [email protected]    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

I am fully with you on this one.

I think I agree with you. Let's have it in.

What about installing a compiler that implements more of C99, like installing a gcc instance? I guess you're on a Sun system, there should be precompiled binaries available.

MfG, JBG

Jan-Benedict Glaw       [email protected]    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Only a subset of C99.

You need SOS10 for full C99 support, Sun have made SOS freely downloadable since version 10.

regards,

Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
It is easier to change the specification to fit the program than vice versa.