{"thread":{"id":"4826","subject":"[PATCH] Avoid C++ comments, use C comments instead","startedAt":"2006-07-10T06:57:51Z","lastAt":"2006-07-11T05:17:27Z","messageCount":14,"participants":["Pavel Roskin","Junio C Hamano","Olivier Galibert","Johannes Schindelin","Paul Serice","Yakov Lerner","Shawn Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"23526","messageId":"20060710065751.22902.43316.stgit@dv.roinet.com","threadId":"4826","inReplyTo":null,"subject":"[PATCH] Avoid C++ comments, use C comments instead","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-07-10T06:57:51Z","receivedAt":"2006-07-10T06:57:51Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"From: Pavel Roskin \n\nThis doesn't make the code uglier or harder to read, yet it makes the\ncode more portable. This also simplifies checking for other potential\nincompatibilities. \"gcc -std=c89 -pedantic\" can flag many incompatible\nconstructs as warnings, but C++ comments will cause it to emit an error.\n\nSigned-off-by: Pavel Roskin \n---\n\n blame.c | 6 +++---\n builtin-apply.c | 21 +++++++++++----------\n builtin-push.c | 2 +-\n convert-objects.c | 10 +++++-----\n dir.c | 2 +-\n http-fetch.c | 6 +++---\n mktag.c | 5 +++--\n read-cache.c | 2 +-\n sha1_file.c | 4 ++--\n ssh-fetch.c | 4 ++--\n 10 files changed, 32 insertions(+), 30 deletions(-)\n\ndiff --git a/blame.c b/blame.c\nindex 0a06026..b04b8f5 100644\n--- a/blame.c\n+++ b/blame.c\n@@ -44,8 +44,8 @@ struct util_info {\n };\n \n struct chunk {\n-\tint off1, len1;\t// ---\n-\tint off2, len2;\t// +++\n+\tint off1, len1;\t/* --- */\n+\tint off2, len2;\t/* +++ */\n };\n \n struct patch {\n@@ -255,7 +255,7 @@ static void print_map(struct commit *cmi\n }\n #endif\n \n-// p is a patch from commit to other.\n+/* p is a patch from commit to other. */\n static void fill_line_map(struct commit *commit, struct commit *other,\n \t\t\t struct patch *p)\n {\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 1e5b846..c903146 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -14,14 +14,15 @@ #include \"blob.h\"\n #include \"delta.h\"\n #include \"builtin.h\"\n \n-// --check turns on checking that the working tree matches the\n-// files that are being modified, but doesn't apply the patch\n-// --stat does just a diffstat, and doesn't actually apply\n-// --numstat does numeric diffstat, and doesn't actually apply\n-// --index-info shows the old and new index info for paths if available.\n-// --index updates the cache as well.\n-// --cached updates only the cache without ever touching the working tree.\n-//\n+/*\n+ * --check turns on checking that the working tree matches the\n+ * files that are being modified, but doesn't apply the patch\n+ * --stat does just a diffstat, and doesn't actually apply\n+ * --numstat does numeric diffstat, and doesn't actually apply\n+ * --index-info shows the old and new index info for paths if available.\n+ * --index updates the cache as well.\n+ * --cached updates only the cache without ever touching the working tree.\n+ */\n static const char *prefix;\n static int prefix_length = -1;\n static int newfd = -1;\n@@ -284,8 +285,8 @@ static void parse_traditional_patch(cons\n {\n \tchar *name;\n \n-\tfirst += 4;\t// skip \"--- \"\n-\tsecond += 4;\t// skip \"+++ \"\n+\tfirst += 4;\t/* skip \"--- \" */\n+\tsecond += 4;\t/* skip \"+++ \" */\n \tif (is_dev_null(first)) {\n \t\tpatch->is_new = 1;\n \t\tpatch->is_delete = 0;\ndiff --git a/builtin-push.c b/builtin-push.c\nindex a8fac88..31cbfd7 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -273,7 +273,7 @@ static int do_push(const char *repo)\n int cmd_push(int argc, const char **argv, char **envp)\n {\n \tint i;\n-\tconst char *repo = \"origin\";\t// default repository\n+\tconst char *repo = \"origin\";\t/* default repository */\n \n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\ndiff --git a/convert-objects.c b/convert-objects.c\nindex 0fabd89..478571f 100644\n--- a/convert-objects.c\n+++ b/convert-objects.c\n@@ -241,13 +241,13 @@ static void convert_date(void *buffer, u\n \tchar *new = xmalloc(size + 100);\n \tunsigned long newlen = 0;\n \t\n-\t// \"tree \\n\"\n+\t/* \"tree \\n\" */\n \tmemcpy(new + newlen, buffer, 46);\n \tnewlen += 46;\n \tbuffer = (char *) buffer + 46;\n \tsize -= 46;\n \n-\t// \"parent \\n\"\n+\t/* \"parent \\n\" */\n \twhile (!memcmp(buffer, \"parent \", 7)) {\n \t\tmemcpy(new + newlen, buffer, 48);\n \t\tnewlen += 48;\n@@ -255,12 +255,12 @@ static void convert_date(void *buffer, u\n \t\tsize -= 48;\n \t}\n \n-\t// \"author xyz date\"\n+\t/* \"author xyz date\" */\n \tnewlen += convert_date_line(new + newlen, &buffer, &size);\n-\t// \"committer xyz date\"\n+\t/* \"committer xyz date\" */\n \tnewlen += convert_date_line(new + newlen, &buffer, &size);\n \n-\t// Rest\n+\t/* Rest */\n \tmemcpy(new + newlen, buffer, size);\n \tnewlen += size;\n \ndiff --git a/dir.c b/dir.c\nindex d778ecd..092d077 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -336,7 +336,7 @@ static int read_directory_recursive(stru\n \t\t\t\tif (dir->show_other_directories &&\n \t\t\t\t (subdir || !dir->hide_empty_directories) &&\n \t\t\t\t !dir_exists(fullname, baselen + len)) {\n-\t\t\t\t\t// Rewind the read subdirectory\n+\t\t\t\t\t/* Rewind the read subdirectory */\n \t\t\t\t\twhile (dir->nr > rewind_base)\n \t\t\t\t\t\tfree(dir->entries[--dir->nr]);\n \t\t\t\t\tbreak;\ndiff --git a/http-fetch.c b/http-fetch.c\nindex 44eba5f..12493fb 100644\n--- a/http-fetch.c\n+++ b/http-fetch.c\n@@ -490,7 +490,7 @@ static int setup_index(struct alt_base *\n {\n \tstruct packed_git *new_pack;\n \tif (has_pack_file(sha1))\n-\t\treturn 0; // don't list this as something we can get\n+\t\treturn 0; /* don't list this as something we can get */\n \n \tif (fetch_index(repo, sha1))\n \t\treturn -1;\n@@ -570,7 +570,7 @@ static void process_alternates_response(\n \t\t\t\t\t\t base[serverlen - 1] != '/');\n \t\t\t\t\ti += 3;\n \t\t\t\t}\n-\t\t\t\t// If the server got removed, give up.\n+\t\t\t\t/* If the server got removed, give up. */\n \t\t\t\tokay = strchr(base, ':') - base + 3 <\n \t\t\t\t\tserverlen;\n \t\t\t} else if (alt_req->http_specific) {\n@@ -581,7 +581,7 @@ static void process_alternates_response(\n \t\t\t\t\tokay = 1;\n \t\t\t\t}\n \t\t\t}\n-\t\t\t// skip 'objects' at end\n+\t\t\t/* skip 'objects' at end */\n \t\t\tif (okay) {\n \t\t\t\ttarget = xmalloc(serverlen + posn - i - 6);\n \t\t\t\tstrlcpy(target, base, serverlen);\ndiff --git a/mktag.c b/mktag.c\nindex f0fe528..27f4c4f 100644\n--- a/mktag.c\n+++ b/mktag.c\n@@ -17,7 +17,7 @@ #include \"tag.h\"\n * in that size, you're doing something wrong.\n */\n \n-// Some random size\n+/* Some random size */\n #define MAXSIZE (8192)\n \n /*\n@@ -123,7 +123,8 @@ int main(int argc, char **argv)\n \t\tdie(\"could not read from stdin\");\n \t}\n \n-\t// Verify it for some basic sanity: it needs to start with \"object \\ntype\\ntagger \"\n+\t/* Verify it for some basic sanity: it needs to start with\n+\t \"object \\ntype\\ntagger \" */\n \tif (verify_tag(buffer, size) < 0)\n \t\tdie(\"invalid tag signature file\");\n \ndiff --git a/read-cache.c b/read-cache.c\nindex 3c32aae..a50d361 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -748,7 +748,7 @@ int read_cache(void)\n \t\tdie(\"index file open failed (%s)\", strerror(errno));\n \t}\n \n-\tsize = 0; // avoid gcc warning\n+\tsize = 0; /* avoid gcc warning */\n \tmap = MAP_FAILED;\n \tif (!fstat(fd, &st)) {\n \t\tsize = st.st_size;\ndiff --git a/sha1_file.c b/sha1_file.c\nindex f7bb3a1..459430a 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -453,7 +453,7 @@ int use_packed_git(struct packed_git *p)\n {\n \tif (!p->pack_size) {\n \t\tstruct stat st;\n-\t\t// We created the struct before we had the pack\n+\t\t/* We created the struct before we had the pack */\n \t\tstat(p->pack_name, &st);\n \t\tif (!S_ISREG(st.st_mode))\n \t\t\tdie(\"packfile %s not a regular file\", p->pack_name);\n@@ -1504,7 +1504,7 @@ static void *repack_object(const unsigne\n \tint hdrlen;\n \tvoid *buf;\n \n-\t// need to unpack and recompress it by itself\n+\t/* need to unpack and recompress it by itself */\n \tunpacked = read_packed_sha1(sha1, type, &len);\n \n \thdrlen = sprintf(hdr, \"%s %lu\", type, len) + 1;\ndiff --git a/ssh-fetch.c b/ssh-fetch.c\nindex 1e59cd2..28f7fd9 100644\n--- a/ssh-fetch.c\n+++ b/ssh-fetch.c\n@@ -68,7 +68,7 @@ int fetch(unsigned char *sha1)\n \tstruct object_list *temp;\n \n \tif (memcmp(sha1, in_transit->item->sha1, 20)) {\n-\t\t// we must have already fetched it to clean the queue\n+\t\t/* we must have already fetched it to clean the queue */\n \t\treturn has_sha1_file(sha1) ? 0 : -1;\n \t}\n \tprefetches--;\n@@ -85,7 +85,7 @@ int fetch(unsigned char *sha1)\n \t\tif (read(fd_in, &remote, 1) < 1)\n \t\t\treturn -1;\n \t}\n-\t//fprintf(stderr, \"Got %d\\n\", remote);\n+\t/* fprintf(stderr, \"Got %d\\n\", remote); */\n \tif (remote < 0)\n \t\treturn remote;\n \tret = write_sha1_from_fd(sha1, fd_in, conn_buf, 4096, &conn_buf_posn);\n"},{"id":"23528","messageId":"7vzmfhdhrf.fsf@assigned-by-dhcp.cox.net","threadId":"4826","inReplyTo":"20060710065751.22902.43316.stgit@dv.roinet.com","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-10T07:46:28Z","receivedAt":"2006-07-10T07:46:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> From: Pavel Roskin \n>\n> This doesn't make the code uglier or harder to read, yet it makes the\n> code more portable. This also simplifies checking for other potential\n> incompatibilities. \"gcc -std=c89 -pedantic\" can flag many incompatible\n> constructs as warnings, but C++ comments will cause it to emit an error.\n>\n> Signed-off-by: Pavel Roskin \n\nThe title should probably read \"avoid C99 comments\", but coming\nfrom the previous century, I tend to agree with this.\n\nThe struct/array initializer stuff by Shawn makes them harder to\nread (for structs, it moves initialization to actual code) and\nmore error prone (for arrays, now the initializers need to be\ncarefully kept ordered), but we do not have too many of them in\nthe code, so I do not think it is a not much of a practical\nproblem. It is sad that some people stay behind and we need to\ncater to them, though.\n"},{"id":"23534","messageId":"20060710094653.GA52962@dspnet.fr.eu.org","threadId":"4826","inReplyTo":"7vzmfhdhrf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-07-10T09:46:53Z","receivedAt":"2006-07-10T09:46:53Z","isPatch":true,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:\n> It is sad that some people stay behind and we need to\n> cater to them, though.\n\nDo you, really?\n\n OG.\n"},{"id":"23536","messageId":"Pine.LNX.4.63.0607101306030.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4826","inReplyTo":"20060710094653.GA52962@dspnet.fr.eu.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-10T11:06:44Z","receivedAt":"2006-07-10T11:06:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Jul 2006, Olivier Galibert wrote:\n\n> On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:\n> > It is sad that some people stay behind and we need to\n> > cater to them, though.\n> \n> Do you, really?\n\nWell, I guess as long as things do not break for _you_, we do not need to.\n\nCiao,\nDscho\n"},{"id":"23538","messageId":"20060710114117.GA62514@dspnet.fr.eu.org","threadId":"4826","inReplyTo":"Pine.LNX.4.63.0607101306030.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-07-10T11:41:18Z","receivedAt":"2006-07-10T11:41:18Z","isPatch":true,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Mon, Jul 10, 2006 at 01:06:44PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 10 Jul 2006, Olivier Galibert wrote:\n> \n> > On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:\n> > > It is sad that some people stay behind and we need to\n> > > cater to them, though.\n> > \n> > Do you, really?\n> \n> Well, I guess as long as things do not break for _you_, we do not need to.\n\nSupporting old, not-standard-anymore compilers has a cost in\nmaintainability, by precluding the use of better constructs (//\ncomments, declarations near initialisation, struct initializers...).\nAdditionally, it gets harder and harder to have people test for them.\nGiven than you can find gcc on pretty much everything that has a\nfilesystem cache decent enough to handle git correctly, is this cost\nworth it? _That_ was the question.\n\n OG.\n"},{"id":"23568","messageId":"44B2A709.8020500@serice.net","threadId":"4826","inReplyTo":"20060710114117.GA62514@dspnet.fr.eu.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Paul Serice","fromEmail":"paul@serice.net","sentAt":"2006-07-10T19:14:17Z","receivedAt":"2006-07-10T19:14:17Z","isPatch":true,"sender":{"key":"paul@serice.net","avatar":null},"body":"> Given than you can find gcc on pretty much everything that has a\n> filesystem cache decent enough to handle git correctly, is this cost\n> worth it? _That_ was the question.\n\nI've seen this argument before. Unfortunately it seems reasonable\nenough on the surface, and I actually bought into it much to may later\nregret.\n\nMy experience is that gcc often produces buggy code, and if gcc is not\n_the_ compiler for that platform, those bugs do not get fixed.\nSpecifically, I have had lots of problems with gcc and IRIX.\n\nIf you want to write portable code, you have to take into account\ndifferent operating systems _and_ different compilers. Writing your\ncode for just a single compiler is almost as bad as writing your code\nfor just a single operating system.\n\nPaul Serice\n"},{"id":"23575","messageId":"20060710202412.GA8189@dspnet.fr.eu.org","threadId":"4826","inReplyTo":"44B2A709.8020500@serice.net","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-07-10T20:24:12Z","receivedAt":"2006-07-10T20:24:12Z","isPatch":true,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:\n> If you want to write portable code, you have to take into account\n> different operating systems _and_ different compilers. Writing your\n> code for just a single compiler is almost as bad as writing your code\n> for just a single operating system.\n\nHmmm, that was not so much about gcc-specific code than which kind of\nC you want to code to, the one from 1973, the one from 1989 or the one\nfrom 1999? I personally don't have much sympathy for the OS vendors\ngiving you an older standard C compiler and selling you the up-to-date\none.\n\n OG.\n"},{"id":"23591","messageId":"Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4826","inReplyTo":"20060710202412.GA8189@dspnet.fr.eu.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-10T22:55:59Z","receivedAt":"2006-07-10T22:55:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Jul 2006, Olivier Galibert wrote:\n\n> On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:\n> > If you want to write portable code, you have to take into account\n> > different operating systems _and_ different compilers. Writing your\n> > code for just a single compiler is almost as bad as writing your code\n> > for just a single operating system.\n> \n> Hmmm, that was not so much about gcc-specific code than which kind of\n> C you want to code to, the one from 1973, the one from 1989 or the one\n> from 1999? I personally don't have much sympathy for the OS vendors\n> giving you an older standard C compiler and selling you the up-to-date\n> one.\n\nJudging by what you say, one could get the impression you'd have not much \nsympathy for people being stuck with non-C99 compilers.\n\nJust look at it: if the OS vendor just does not _care_, and you blame the \nvendor for not providing something newer, the vendor does not _care_ about \nyour complaint either. But the user does.\n\nHowever, there is a more important point to be made. If you are complying \nwith an older standard, you get more users. More users = more bug testers.\n\nAnd there were quite a few occasions where I found bugs by trying to run \non a different platform, which was less forgiving than Linux. These are \nbugs you have a harder time to spot on Linux, _because_ Linux is so nice. \nBut they will surface. And they will be a PITA to find.\n\nAnyway, it is best practice for a reason to program portably. (Well, at \nleast if you are not living in Redmont.)\n\nCiao,\nDscho\n"},{"id":"23595","messageId":"f36b08ee0607101625y6eaec83ck22dd20b4f27a1846@mail.gmail.com","threadId":"4826","inReplyTo":"Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2006-07-10T23:25:44Z","receivedAt":"2006-07-10T23:25:44Z","isPatch":true,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"On 7/11/06, Johannes Schindelin wrote:\n> Hi,\n>\n> On Mon, 10 Jul 2006, Olivier Galibert wrote:\n>\n> > On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:\n> > > If you want to write portable code, you have to take into account\n> > > different operating systems _and_ different compilers. Writing your\n> > > code for just a single compiler is almost as bad as writing your code\n> > > for just a single operating system.\n> >\n> > Hmmm, that was not so much about gcc-specific code than which kind of\n> > C you want to code to, the one from 1973, the one from 1989 or the one\n> > from 1999? I personally don't have much sympathy for the OS vendors\n> > giving you an older standard C compiler and selling you the up-to-date\n> > one.\n>\n> Judging by what you say, one could get the impression you'd have not much\n> sympathy for people being stuck with non-C99 compilers.\n>\n> Just look at it: if the OS vendor just does not _care_, and you blame the\n> vendor for not providing something newer, the vendor does not _care_ about\n> your complaint either. But the user does.\n>\n> However, there is a more important point to be made. If you are complying\n> with an older standard, you get more users. More users = more bug testers.\n>\n> And there were quite a few occasions where I found bugs by trying to run\n> on a different platform, which was less forgiving than Linux. These are\n> bugs you have a harder time to spot on Linux, _because_ Linux is so nice.\n> But they will surface. And they will be a PITA to find.\n>\n> Anyway, it is best practice for a reason to program portably. (Well, at\n> least if you are not living in Redmont.)\n\nBack in the beginning of nineties, c89 was new and the\nprototypes was not yet impemented on many compilers.\nOne good trick of the time was automatic\nsource conversion. This protoize/unprotoize tool converted\nsources from non-prototyped form to\nprototyped, and the other way. (There was also #ifdef-trick\nwhich was ugly as hell for the same purpose, and the __P()\nmacro trick, which was less ugly).\n\nThe benefit was that you got the benefit of both worlds,\n(1) the benefit of prototypes when compiler was c89-compliant, and\n(2) compilability with pre-c89 compilers when needed.\n\nI am writing in order to ask, whether there maybe\nsome c99-to-c89 source convertor that can be\nautomatically applied to the .c before compiling with\npre-c99 compiler ?\n\nYakov\n"},{"id":"23597","messageId":"20060710234234.GA26528@dspnet.fr.eu.org","threadId":"4826","inReplyTo":"Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-07-10T23:42:34Z","receivedAt":"2006-07-10T23:42:34Z","isPatch":true,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Tue, Jul 11, 2006 at 12:55:59AM +0200, Johannes Schindelin wrote:\n> Judging by what you say, one could get the impression you'd have not much \n> sympathy for people being stuck with non-C99 compilers.\n\nMore and more these people are stuck with such a compiler because they\nwant to be.\n\n\n> Just look at it: if the OS vendor just does not _care_, and you blame the \n> vendor for not providing something newer, the vendor does not _care_ about \n> your complaint either. But the user does.\n\nWell, I'm not talking about git here, but I'm not really interested in\nmaking my code harder to maintain just to provide more value for said\nvendor.\n\n\n> However, there is a more important point to be made. If you are complying \n> with an older standard, you get more users. More users = more bug testers.\n\nOn such systems, what you tend to find is bugs of the system, or\nsimply different, and sometimes somewhat nonsensical, implementations\nof some compromise-happy standards like POSIX.\n\n\n> And there were quite a few occasions where I found bugs by trying to run \n> on a different platform, which was less forgiving than Linux. These are \n> bugs you have a harder time to spot on Linux, _because_ Linux is so nice. \n> But they will surface. And they will be a PITA to find.\n\nAnd how many bugs or \"features\" of the platform did you have to code\naround before finding a genuine bug?\n\n\n> Anyway, it is best practice for a reason to program portably. (Well, at \n> least if you are not living in Redmont.)\n\nIf \"programming portably\" meant catering to the oldest standards, then\nyou shouldn't even use prototypes or ansi-style function declarations.\nAfter all, some people may be stuck with the old sun (or was it hp?)\ncompiler that was k&r only. And limit the filenames to 14 characters.\nAlso, you shouldn't require gtk, python, perl, fire or the wheel.\n\n OG.\n"},{"id":"23598","messageId":"20060710235122.GB26528@dspnet.fr.eu.org","threadId":"4826","inReplyTo":"f36b08ee0607101625y6eaec83ck22dd20b4f27a1846@mail.gmail.com","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-07-10T23:51:22Z","receivedAt":"2006-07-10T23:51:22Z","isPatch":true,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:\n> I am writing in order to ask, whether there maybe\n> some c99-to-c89 source convertor that can be\n> automatically applied to the .c before compiling with\n> pre-c99 compiler ?\n\nComments are easy. Moving declarations without breaking initializers\nis harder. Rewriting the struct initializers is pretty much\nimpossible without the tool turning into a full-blown C parser.\n\nMaybe git can be perfectly happy with c89. I don't know. I know the\nlinux kernel requires c99, mostly for the struct initializers. My\npoint was that staying at the c89 level has a maintainance cost, and a\ncost/benefit analysis should be done to decide whether it is a good\nidea. Answering \"get a C compiler\", as is being done for some years\nnow for people not wanting prototypes, is an option not to neglect.\n\n OG.\n"},{"id":"23600","messageId":"20060711001504.GA10700@spearce.org","threadId":"4826","inReplyTo":"20060710235122.GB26528@dspnet.fr.eu.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-11T00:15:05Z","receivedAt":"2006-07-11T00:15:05Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Olivier Galibert wrote:\n> On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:\n> > I am writing in order to ask, whether there maybe\n> > some c99-to-c89 source convertor that can be\n> > automatically applied to the .c before compiling with\n> > pre-c99 compiler ?\n> \n> Comments are easy. Moving declarations without breaking initializers\n> is harder. Rewriting the struct initializers is pretty much\n> impossible without the tool turning into a full-blown C parser.\n> \n> Maybe git can be perfectly happy with c89. I don't know. I know the\n> linux kernel requires c99, mostly for the struct initializers. My\n> point was that staying at the c89 level has a maintainance cost, and a\n> cost/benefit analysis should be done to decide whether it is a good\n> idea. Answering \"get a C compiler\", as is being done for some years\n> now for people not wanting prototypes, is an option not to neglect.\n\nGIT 1.2.3 had a lot more struct initializers than GIT 1.4.1 has. So\napparently it was cleaner to remove a few of them in some cases then\nit was to keep them in. But that's besides the point.\n\nI can understand the core maintainers not wanting to apply my patch\nand lose the benefits of c99, and if I have to I'll carry a private\nbranch with that patch and hand-edit future versions as necessary\nto get the same result... but I'd hate to see another user have\nto do the same work for the same reason.\n\nI'm not a big contributor to GIT (I certainly don't contribute\nnearly as much code as most others) and I'm also not a big user of\nGIT (I don't develop for the Linux kernel) so I not expecting the\ncore to drop to c89 just for me and this old compiler. :-)\n\nAfter reading this thread I'm thinking that this probably shouldn't\nget merged in and that I should carry the tweaks locally to get\nGIT to build on the only compiler I have available on that system.\nNow that GIT 1.4.1 is installed on there I'm unlikely to upgrade it\nfor at least 6 months, as I'm using only the very low level plumbing\n(git-read-tree, git-write-tree, git-update-index, git-repack).\nRemerging these c99 downgrades at that time shouldn't be a huge\nissue for me since its probably going to be done so infrequently.\n\n-- \nShawn.\n"},{"id":"23604","messageId":"7vbqrx6ku8.fsf@assigned-by-dhcp.cox.net","threadId":"4826","inReplyTo":"20060711001504.GA10700@spearce.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-11T00:34:07Z","receivedAt":"2006-07-11T00:34:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Olivier Galibert wrote:\n>>\n>> Maybe git can be perfectly happy with c89. I don't know. I know the\n>> linux kernel requires c99, mostly for the struct initializers. My\n>> point was that staying at the c89 level has a maintainance cost, and a\n>> cost/benefit analysis should be done to decide whether it is a good\n>> idea.\n\nI am generally in favor of the effect C99 struct and array\ninitializers have on the readability, but we also need to\nbalance that with the reality. The patch is only about a few\nstructs and one array if I recall correctly isn't it?\n\nWhat Olivier says is perfectly correct, and after \"cost/benefit\nanalysis\", I would have to say avoiding some C99 is fine if that\nmakes people's life on some major non-Linux platforms easier.\n\nC99 clean-up is already in the \"master\", so please do not waste\nmore bandwidth nor time on this issue, but instead spend time\nelsewhere to make our system better for more people ;-).\n\nThanks.\n"},{"id":"23613","messageId":"1152595047.29932.9.camel@dv","threadId":"4826","inReplyTo":"20060710114117.GA62514@dspnet.fr.eu.org","subject":"Re: [PATCH] Avoid C++ comments, use C comments instead","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-07-11T05:17:27Z","receivedAt":"2006-07-11T05:17:27Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nOn Mon, 2006-07-10 at 13:41 +0200, Olivier Galibert wrote:\n> Supporting old, not-standard-anymore compilers has a cost in\n> maintainability, by precluding the use of better constructs (//\n> comments, declarations near initialisation, struct initializers...).\n> Additionally, it gets harder and harder to have people test for them.\n\nSorry for one more addition to this thread. I just want to clear some\nmisunderstanding. The whole point of fixing the comments is to make is\neasier to test for other compatibility issues using gcc.\n\nFor gcc to report post-c89 features, \"-pedantic -std=c89\" should be\nsupplied. This option makes gcc report the c99 comments as errors and\nother c99 features as warnings. The errors would stand in the way of\nfinding the warnings.\n\nI'm not saying all non-c89 constructs should be fixed, but if we get a\nreport that some feature is not working with some compiler, we could\ncompile git with \"-pedantic -std=c89\", find corresponding warnings and\nfix them. The comments would stand in the way for somebody using gcc.\n\n-- \nRegards,\nPavel Roskin\n"}]}