{"thread":{"id":"10870","subject":"[PATCH] Fix Solaris Workshop Compiler issues","startedAt":"2007-11-14T20:31:13Z","lastAt":"2007-11-20T20:09:41Z","messageCount":31,"participants":["Guido Ostkamp","Alex Riesen","Junio C Hamano","Björn Steinbrink","Linus Torvalds","David Kastrup","Martin Mares"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"59873","messageId":"Pine.LNX.4.64.0711142125460.17530@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":null,"subject":"[PATCH] Fix Solaris Workshop Compiler issues","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-14T20:31:13Z","receivedAt":"2007-11-14T20:31:13Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"Hello,\n\nplease find below a patch that solves an error when compiling with the \noriginal Sun Solaris Compiler. When compiling out of the box, the \nfollowing happens:\n\n CC diff-delta.o\n\"diff-delta.c\", line 314: identifier redeclared: create_delta\n \tcurrent : function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void\n \tprevious: function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void : \"delta.h\", line 44\ncc: acomp failed for diff-delta.c\nmake: *** [diff-delta.o] Error 2\n\nThis is because 'struct delta_index' is declared with no size in delta.h \nand with size in diff-delta.c which does not fit.\n\nWhen the struct definition is done in the header file as one would \nnormally expect, everything compiles ok with exception of a \nmkdtemp()-issue which somebody else already took care of on this list.\n\nBest regards\n\nGuido\n\n\ndiff --git a/delta.h b/delta.h\nindex 40ccf5a..06af9a7 100644\n--- a/delta.h\n+++ b/delta.h\n@@ -1,8 +1,23 @@\n #ifndef DELTA_H\n #define DELTA_H\n\n-/* opaque object for delta index */\n-struct delta_index;\n+struct index_entry {\n+ const unsigned char *ptr;\n+ unsigned int val;\n+};\n+\n+struct unpacked_index_entry {\n+ struct index_entry entry;\n+ struct unpacked_index_entry *next;\n+};\n+\n+struct delta_index {\n+ unsigned long memsize;\n+ const void *src_buf;\n+ unsigned long src_size;\n+ unsigned int hash_mask;\n+ struct index_entry *hash[FLEX_ARRAY];\n+};\n\n /*\n * create_delta_index: compute index data from given buffer\ndiff --git a/diff-delta.c b/diff-delta.c\nindex 9e440a9..2023e40 100644\n--- a/diff-delta.c\n+++ b/diff-delta.c\n@@ -112,24 +112,6 @@ static const unsigned int U[256] = {\n \t0x133eb0ac, 0x6d8b90a1, 0x450d4467, 0x3bb8646a\n };\n\n-struct index_entry {\n-\tconst unsigned char *ptr;\n-\tunsigned int val;\n-};\n-\n-struct unpacked_index_entry {\n-\tstruct index_entry entry;\n-\tstruct unpacked_index_entry *next;\n-};\n-\n-struct delta_index {\n-\tunsigned long memsize;\n-\tconst void *src_buf;\n-\tunsigned long src_size;\n-\tunsigned int hash_mask;\n-\tstruct index_entry *hash[FLEX_ARRAY];\n-};\n-\n struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)\n {\n \tunsigned int i, hsize, hmask, entries, prev_val, *hash_count;\n"},{"id":"59877","messageId":"20071114204732.GE3973@steel.home","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711142125460.17530@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-14T20:47:32Z","receivedAt":"2007-11-14T20:47:32Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Guido Ostkamp, Wed, Nov 14, 2007 21:31:13 +0100:\n> Hello,\n>\n> please find below a patch that solves an error when compiling with the \n> original Sun Solaris Compiler. When compiling out of the box, the following \n> happens:\n>\n> CC diff-delta.o\n> \"diff-delta.c\", line 314: identifier redeclared: create_delta\n> \tcurrent : function(pointer to const struct delta_index {unsigned long \n> memsize, pointer to const void src_buf, unsigned long src_size, unsigned \n> int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, \n> pointer to const void, unsigned long, pointer to unsigned long, unsigned \n> long) returning pointer to void\n> \tprevious: function(pointer to const struct delta_index {unsigned long \n> memsize, pointer to const void src_buf, unsigned long src_size, unsigned \n> int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, \n> pointer to const void, unsigned long, pointer to unsigned long, unsigned \n> long) returning pointer to void : \"delta.h\", line 44\n\nThe both prototypes listed are *exactly* the same. And both are wrong.\nLooks like you're dealing with typically broken Sun compiler.\n\nTry defining const to nothing or removing it from this prototype.\nI suspect the thing is just so old and broken that it does not even\nknow anything of const.\n\n> cc: acomp failed for diff-delta.c\n> make: *** [diff-delta.o] Error 2\n>\n> This is because 'struct delta_index' is declared with no size in delta.h \n> and with size in diff-delta.c which does not fit.\n\nHuh?! Ever heard of forward declaration?\n"},{"id":"59879","messageId":"7vprycfrk6.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"20071114204732.GE3973@steel.home","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-14T21:25:13Z","receivedAt":"2007-11-14T21:25:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Guido Ostkamp, Wed, Nov 14, 2007 21:31:13 +0100:\n>> ...\n>> cc: acomp failed for diff-delta.c\n>> make: *** [diff-delta.o] Error 2\n>>\n>> This is because 'struct delta_index' is declared with no size in delta.h \n>> and with size in diff-delta.c which does not fit.\n>\n> Huh?! Ever heard of forward declaration?\n\nWe are not the first people who pass around a pointer to an\nopaque struct in the API to hide away the implementation. It\nwould be surprising if the Workshop Compiler chokes on this and\nnot other projects.\n"},{"id":"59887","messageId":"Pine.LNX.4.64.0711150011020.4135@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7vprycfrk6.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-14T23:21:55Z","receivedAt":"2007-11-14T23:21:55Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"On Wed, 14 Nov 2007, Junio C Hamano wrote:\n\n> Alex Riesen writes:\n>\n>> Guido Ostkamp, Wed, Nov 14, 2007 21:31:13 +0100:\n>>> ...\n>>> cc: acomp failed for diff-delta.c\n>>> make: *** [diff-delta.o] Error 2\n>>>\n>>> This is because 'struct delta_index' is declared with no size in delta.h\n>>> and with size in diff-delta.c which does not fit.\n>>\n>> Huh?! Ever heard of forward declaration?\n>\n> We are not the first people who pass around a pointer to an opaque \n> struct in the API to hide away the implementation. It would be \n> surprising if the Workshop Compiler chokes on this and not other \n> projects.\n\nYou got the original error report from Sun's compiler included in my \nearlier email. This happens with at least Sun Forte 6.1 (Solaris 8) and \nSun Workshop 11 (Solaris 10), IIRC.\n\nThe function declarations regarding create_delta() in delta.h and \ndiff-delta.c are identical with respect to the type names of the parameter \n(only some internal names e.g. like 'buf' vs. 'trg_buf' are slightly \ndifferent, but this has no effect).\n\nThe main difference is that the 'struct delta_index' is opaque in delta.h \nand non-opaque in diff-delta.c; the patch clearly shows it solves the \nerror. So we've got a solution.\n\nIf you feel we could try something else, please let me know and I'll check \nit out.\n\nPlease keep me on CC, as I'm not subscribed to the list, thanks.\n\nRegards\n\nGuido\n"},{"id":"59888","messageId":"20071114232809.GH3973@steel.home","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711150011020.4135@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-14T23:28:09Z","receivedAt":"2007-11-14T23:28:09Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Guido Ostkamp, Thu, Nov 15, 2007 00:21:55 +0100:\n> The main difference is that the 'struct delta_index' is opaque in delta.h \n> and non-opaque in diff-delta.c; the patch clearly shows it solves the \n> error. So we've got a solution.\n\nIt is not the solution. How do you think the rest of Git compiles?\n\n> If you feel we could try something else, please let me know and I'll check \n> it out.\n\nYes. Read the mail I sent before:\n\n Try removing the \"const\". Looks like that compiler is too stupid\n to understand it.\n"},{"id":"59890","messageId":"20071115001756.GA25021@atjola.homenet","threadId":"10870","inReplyTo":"20071114232809.GH3973@steel.home","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-15T00:17:56Z","receivedAt":"2007-11-15T00:17:56Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.15 00:28:09 +0100, Alex Riesen wrote:\n> Guido Ostkamp, Thu, Nov 15, 2007 00:21:55 +0100:\n> > The main difference is that the 'struct delta_index' is opaque in delta.h \n> > and non-opaque in diff-delta.c; the patch clearly shows it solves the \n> > error. So we've got a solution.\n> \n> It is not the solution. How do you think the rest of Git compiles?\n> \n> > If you feel we could try something else, please let me know and I'll check \n> > it out.\n> \n> Yes. Read the mail I sent before:\n> \n> Try removing the \"const\". Looks like that compiler is too stupid\n> to understand it.\n\nNo, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05\n\nIt's the \"struct hack\", ie. the incomplete array at the end of\ndelta_index. Still looking for a fix/workaround.\n\nBjörn\n"},{"id":"59894","messageId":"7v3av89wq7.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"20071115001756.GA25021@atjola.homenet","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T00:30:08Z","receivedAt":"2007-11-15T00:30:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> No, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05\n>\n> It's the \"struct hack\", ie. the incomplete array at the end of\n> delta_index. Still looking for a fix/workaround.\n\nDo you mean the \"FLEX_ARRAY\" thing?\n\nYou can ask for FLEX_ARRAY from the command line of your \"make\"\nprocess.\n\nThere is this thing in git-compat-util.h\n\n #ifndef FLEX_ARRAY\n #if defined(__GNUC__) && (__GNUC__ < 3)\n #define FLEX_ARRAY 0\n #else\n #define FLEX_ARRAY /* empty */\n #endif\n #endif\n\nThe sources are written this way:\n\n\tstruct foo {\n \t... other members ...\n char last_member_that_is_flexible[FLEX_ARRAY];\n\t};\n\nFor older gcc, because we know about its lack of support, the\nabove turns into:\n\n\tstruct foo {\n \t... other members ...\n char last_member_that_is_flexible[0];\n }\n\nBut for recent enough compilers that grok the \"flexible array\nmembers\", the above expands to:\n\n\tstruct foo {\n \t... other members ...\n char last_member_that_is_flexible[];\n }\n\nMaybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n"},{"id":"59895","messageId":"20071115004404.GB25021@atjola.homenet","threadId":"10870","inReplyTo":"7v3av89wq7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-15T00:44:04Z","receivedAt":"2007-11-15T00:44:04Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> > No, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05\n> >\n> > It's the \"struct hack\", ie. the incomplete array at the end of\n> > delta_index. Still looking for a fix/workaround.\n> \n> Do you mean the \"FLEX_ARRAY\" thing?\n> \n> You can ask for FLEX_ARRAY from the command line of your \"make\"\n> process.\n> \n> There is this thing in git-compat-util.h\n> \n> #ifndef FLEX_ARRAY\n> #if defined(__GNUC__) && (__GNUC__ < 3)\n> #define FLEX_ARRAY 0\n> #else\n> #define FLEX_ARRAY /* empty */\n> #endif\n> #endif\n> \n> The sources are written this way:\n> \n> \tstruct foo {\n> \t... other members ...\n> char last_member_that_is_flexible[FLEX_ARRAY];\n> \t};\n> \n> For older gcc, because we know about its lack of support, the\n> above turns into:\n> \n> \tstruct foo {\n> \t... other members ...\n> char last_member_that_is_flexible[0];\n> }\n> \n> But for recent enough compilers that grok the \"flexible array\n> members\", the above expands to:\n> \n> \tstruct foo {\n> \t... other members ...\n> char last_member_that_is_flexible[];\n> }\n> \n> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n\nActually, I just created a test-case remotely on a Solaris box in my\nuniversity (see below) and didn't compile the actual git code. With the\nFAM, cc complains about a redeclared identifier, with a zero-sized\narray, it complains that an array cannot be zero-sized...\n\nSeems to be a known bug in Sun Studio 10:\nhttp://forum.java.sun.com/thread.jspa?threadID=5071896&messageID=9263771\n\nBjörn\n\n\n#include \n\nstruct foo;\nvoid bar(const struct foo *, unsigned long);\n\nstruct bla {\n\tunsigned long foo;\n};\n\nstruct foo {\n\tunsigned long val;\n\tstruct bla *blas[];\n};\n\nvoid bar(const struct foo *foo, unsigned long val)\n{\n\tprintf(\"%lu %lu\\n\", foo->val, val);\n}\n\nint main()\n{\n\tstruct foo foo;\n\tfoo.val = 10;\n\tbar(&foo, 20);\n\n\treturn 0;\n}\n"},{"id":"59896","messageId":"alpine.LFD.0.9999.0711141640400.2786@woody.linux-foundation.org","threadId":"10870","inReplyTo":"7v3av89wq7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-15T00:44:05Z","receivedAt":"2007-11-15T00:44:05Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Nov 2007, Junio C Hamano wrote:\n> \n> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n\nActually, for old pre-C99 compilers, you're probably better off using \n-DFLEX_ARRAY=1, since a zero-sized array could be considered bogus by \nsome.\n\n\t\t\tLinus\n"},{"id":"59897","messageId":"7vy7d08her.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"20071115004404.GB25021@atjola.homenet","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T00:46:20Z","receivedAt":"2007-11-15T00:46:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:\n>\n>> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n>\n> Actually, I just created a test-case remotely on a Solaris box in my\n> university (see below) and didn't compile the actual git code. With the\n> FAM, cc complains about a redeclared identifier, with a zero-sized\n> array, it complains that an array cannot be zero-sized...\n\nI think you can pass -DFLEX_ARRAY=1 as a workaround. It would\nwaste one array member in a flexible structure but that is\nbetter than compiler choking.\n"},{"id":"59899","messageId":"20071115005011.GC25021@atjola.homenet","threadId":"10870","inReplyTo":"7vy7d08her.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-15T00:50:11Z","receivedAt":"2007-11-15T00:50:11Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.14 16:46:20 -0800, Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> > On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:\n> >\n> >> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n> >\n> > Actually, I just created a test-case remotely on a Solaris box in my\n> > university (see below) and didn't compile the actual git code. With the\n> > FAM, cc complains about a redeclared identifier, with a zero-sized\n> > array, it complains that an array cannot be zero-sized...\n> \n> I think you can pass -DFLEX_ARRAY=1 as a workaround. It would\n> waste one array member in a flexible structure but that is\n> better than compiler choking.\n\nYeah, that at least compiles (didn't do any further tests), forgot to\nsay that in the last email.\n\nBjörn\n"},{"id":"59900","messageId":"1195089303-28085-1-git-send-email-B.Steinbrink@gmx.de","threadId":"10870","inReplyTo":"7vy7d08her.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-15T01:15:03Z","receivedAt":"2007-11-15T01:15:03Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"Some versions of SUN's cc have a bug that causes them to complain about\na redeclared identifier when you use a function declaration that takes a\nstruct with a FAM and this struct has only been declared but not yet\ndefined.\n\nIOW, this will fail:\n\tstruct foo;\n\n\tvoid bar(struct foo *);\n\n\tstruct foo {\n\t\tint v;\n\t\tlong *a[];\n\t};\n\n\tvoid bar(struct foo *foo) {} // SUN cc bug strikes here\n\nSo when we detect a SUN cc, we use an array size of 1 to workaround that\nbug.\n\nSigned-off-by: Björn Steinbrink \n---\nGuido, could you please test this patch?\n\nI have no clue which versions of SUN's cc are affected, so I simply enabled\nthe workaround for all versions. Someone with more knowledge about that\nshould probably limit the check to only do that for the broken versions.\n\n git-compat-util.h | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex ede9408..c3ff4b4 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -6,6 +6,8 @@\n #ifndef FLEX_ARRAY\n #if defined(__GNUC__) && (__GNUC__ < 3)\n #define FLEX_ARRAY 0\n+#elif defined(sun) || defined(__SUN__)\n+#define FLEX_ARRAY 1\n #else\n #define FLEX_ARRAY /* empty */\n #endif\n-- \n1.5.3.5.643.g40e25\n"},{"id":"59902","messageId":"85ir441exj.fsf@lola.goethe.zz","threadId":"10870","inReplyTo":"alpine.LFD.0.9999.0711141640400.2786@woody.linux-foundation.org","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-15T01:21:44Z","receivedAt":"2007-11-15T01:21:44Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, 14 Nov 2007, Junio C Hamano wrote:\n>> \n>> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?\n>\n> Actually, for old pre-C99 compilers, you're probably better off using \n> -DFLEX_ARRAY=1, since a zero-sized array could be considered bogus by \n> some.\n\nIs that supposed to work? I would have thought that the only options\nwould be empty and 0. I am pretty sure I have seen size calculations in\nthe deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_\n-DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could\ntry seeing whether I find those locations again.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"59907","messageId":"alpine.LFD.0.9999.0711141752230.2786@woody.linux-foundation.org","threadId":"10870","inReplyTo":"85ir441exj.fsf@lola.goethe.zz","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-15T01:53:51Z","receivedAt":"2007-11-15T01:53:51Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 15 Nov 2007, David Kastrup wrote:\n> \n> Is that supposed to work? I would have thought that the only options\n> would be empty and 0.\n\nI think it should work, even though some things allocations will end up \nbeing a bit too large (ie anything that uses \"sizeof()\" will have that one \nunnecessary entry)\n\nBut no, I didn't actually test it.\n\n\t\tLinus\n"},{"id":"59911","messageId":"7vpryc89xu.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"85ir441exj.fsf@lola.goethe.zz","subject":"Re: [PATCH] Fix Solaris Workshop Compiler issues","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T03:27:41Z","receivedAt":"2007-11-15T03:27:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> ... I am pretty sure I have seen size calculations in\n> the deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_\n> -DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could\n> try seeing whether I find those locations again.\n\nI do recall that I received a patch with an explicit member\nelem[1] that is in fact used as a flexible array, foolishly\nconverted it to use FLEX_ARRAY and saw it mysteriously fail, and\nrealized what it was doing and reverted my changes, and applied\nthe patch as received. IIRC it all happened before I pushed the\nresults out. I unfortunately do not recall which area the patch\nwas about.\n"},{"id":"60031","messageId":"Pine.LNX.4.64.0711152253430.4090@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"1195089303-28085-1-git-send-email-B.Steinbrink@gmx.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-15T22:00:44Z","receivedAt":"2007-11-15T22:00:44Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"On Thu, 15 Nov 2007, Björn Steinbrink wrote:\n> Some versions of SUN's cc have a bug that causes them to complain about\n> a redeclared identifier when you use a function declaration that takes a\n> struct with a FAM and this struct has only been declared but not yet\n> defined.\n> [...]\n> Signed-off-by: Björn Steinbrink \n> ---\n> Guido, could you please test this patch?\n\nI tested it and the file in question compiled ok for the two versions of \nSun Forte and Workshop compilers that I have available.\n\nI could also link & run the main git binary after applying my own \nmkdtemp() patch.\n\nI hope your patch will get officially included.\n\nRegards\n\nGuido"},{"id":"60036","messageId":"7v640340kp.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711152253430.4090@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T22:15:50Z","receivedAt":"2007-11-15T22:15:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Guido Ostkamp writes:\n\n> I tested it and the file in question compiled ok for the two versions\n> of Sun Forte and Workshop compilers that I have available.\n>\n> I could also link & run the main git binary after applying my own\n> mkdtemp() patch.\n\nAre there problems with the implementation in compat/ directory,\nwe ship specifically to help platforms without mkdtemp()?\n"},{"id":"60040","messageId":"Pine.LNX.4.64.0711152323510.7501@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7v640340kp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-15T22:28:52Z","receivedAt":"2007-11-15T22:28:52Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"On Thu, 15 Nov 2007, Junio C Hamano wrote:\n> Are there problems with the implementation in compat/ directory, we ship \n> specifically to help platforms without mkdtemp()?\n\nThe Git version that I used for testing at office did not yet include your \ncompat fix or did not activate it automatically.\n\nI shall check this out tomorrow and let you know. Sorry, it's already late \nhere in Germany (23:27h) - I need to get some sleep ;-)\n\nRegards\n\nGuido\n"},{"id":"60051","messageId":"7vd4ua3hww.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"1195089303-28085-1-git-send-email-B.Steinbrink@gmx.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-16T04:58:55Z","receivedAt":"2007-11-16T04:58:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> Guido, could you please test this patch?\n>\n> I have no clue which versions of SUN's cc are affected, so I simply enabled\n> the workaround for all versions. Someone with more knowledge about that\n> should probably limit the check to only do that for the broken versions.\n>\n> git-compat-util.h | 2 ++\n> 1 files changed, 2 insertions(+), 0 deletions(-)\n\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index ede9408..c3ff4b4 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -6,6 +6,8 @@\n> #ifndef FLEX_ARRAY\n> #if defined(__GNUC__) && (__GNUC__ < 3)\n> #define FLEX_ARRAY 0\n> +#elif defined(sun) || defined(__SUN__)\n> +#define FLEX_ARRAY 1\n> #else\n> #define FLEX_ARRAY /* empty */\n> #endif\n\nThis feels a bit too narrow and too broad at the same time,\ndoesn't it?\n\nAs I suspect there are other compilers that do not implement\nflexible array members (so you cannot use \"member[]\") nor older\ngcc extension of zero sized member (so you cannot use\n\"member[0]\" either), this checking specifically for Sun is too\nnarrow.\n\nOn the other hand, as you said, this is too broad, because not\neverybody may be using the SUN compiler on Sun, nor the version\nthat does not understand flexible array members.\n\nBut being broad should always be safer, albeit a bit wasteful.\n\nHow about doing it this way?\n\n # ifndef FLEX_ARRAY\n # if defined(__GNUC__)\n # if (__GNUC__ < 3)\n # define FLEX_ARRAY 0\n # else\n # define FLEX_ARRAY /* empty */\n # endif\n # else\n /* more cases we know we can use 0 or empty can come here */\n # endif\n # endif\n\n /* if still undefined, default to the safe, old fashioned way */\n # ifndef FLEX_ARRAY\n # define FLEX_ARRAY 1\n # endif\n\nThe basic idea is:\n\n * The user (from Makefile command line, config.mak, or you\n could add autoconf test) can pass -DFLEX_ARRAY=... to specify\n exactly what should happen;\n\n * Otherwise, if we happen to know for sure that we can use \"0\"\n or \"/* empty */\" with the compiler, we define FLEX_ARRAY;\n currently we know such things for gcc.\n\n * For everybody else, we use safer default of \"1\". IOW, if you\n know your compiler does not grok \"/* empty */\" nor \"0\", you\n do not have to do anything special but use the default case\n as everybody else.\n"},{"id":"60084","messageId":"20071116125527.GB14473@atjola.homenet","threadId":"10870","inReplyTo":"7vd4ua3hww.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-16T12:55:27Z","receivedAt":"2007-11-16T12:55:27Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.15 20:58:55 -0800, Junio C Hamano wrote:\n> How about doing it this way?\n> \n> # ifndef FLEX_ARRAY\n> # if defined(__GNUC__)\n> # if (__GNUC__ < 3)\n> # define FLEX_ARRAY 0\n> # else\n> # define FLEX_ARRAY /* empty */\n> # endif\n> # else\n> /* more cases we know we can use 0 or empty can come here */\n> # endif\n> # endif\n> \n> /* if still undefined, default to the safe, old fashioned way */\n> # ifndef FLEX_ARRAY\n> # define FLEX_ARRAY 1\n> # endif\n\nYeah, looks a bit smarter.\n\n> The basic idea is:\n> \n> * The user (from Makefile command line, config.mak, or you\n> could add autoconf test) can pass -DFLEX_ARRAY=... to specify\n> exactly what should happen;\n\nEeeek! He said autoconf! Waaah! ... Ehrm, sorry where was I?\n\n> * Otherwise, if we happen to know for sure that we can use \"0\"\n> or \"/* empty */\" with the compiler, we define FLEX_ARRAY;\n> currently we know such things for gcc.\n> \n> * For everybody else, we use safer default of \"1\". IOW, if you\n> know your compiler does not grok \"/* empty */\" nor \"0\", you\n> do not have to do anything special but use the default case\n> as everybody else.\n\nYep, definitely better than my patch.\n\nBjörn\n"},{"id":"60104","messageId":"Pine.LNX.4.64.0711161954510.7139@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7v640340kp.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Add mkdtemp() workaround for Sun Solaris 10","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-16T18:59:58Z","receivedAt":"2007-11-16T18:59:58Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"On Thu, 15 Nov 2007, Junio C Hamano wrote:\n> Are there problems with the implementation in compat/ directory, we ship \n> specifically to help platforms without mkdtemp()?\n\nI checked again and the answer is 'yes'. The reason is trivial - for \nSolaris 10 the workaround is not activated and my version of Solaris 10 \n(Sparc) has no mkdtemp() in libc.so.\n\nThe following patch should fix this:\n\nActivate mkdtemp() workaround for Solaris 10.\n\nSigned-off-by: Guido Ostkamp \n---\n Makefile | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex e830bc7..9dc01df 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -431,6 +431,9 @@ ifeq ($(uname_S),SunOS)\n \t\tNO_C99_FORMAT = YesPlease\n \t\tNO_STRTOUMAX = YesPlease\n \tendif\n+\tifeq ($(uname_R),5.10)\n+\t\tNO_MKDTEMP = YesPlease\n+\tendif\n \tINSTALL = ginstall\n \tTAR = gtar\n \tBASIC_CFLAGS += -D__EXTENSIONS__\n-- \n1.5.3.5.721.g039b\n"},{"id":"60120","messageId":"7vtznlww0t.fsf_-_@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711161954510.7139@bianca.dialin.t-online.de","subject":"[RFH] Solaris portability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-17T00:33:38Z","receivedAt":"2007-11-17T00:33:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Guido Ostkamp writes:\n\n> On Thu, 15 Nov 2007, Junio C Hamano wrote:\n>> Are there problems with the implementation in compat/ directory, we\n>> ship specifically to help platforms without mkdtemp()?\n>\n> I checked again and the answer is 'yes'. The reason is trivial - for\n> Solaris 10 the workaround is not activated and my version of Solaris\n> 10 (Sparc) has no mkdtemp() in libc.so.\n\nThanks.\n\nThis makes me wonder if treating it just like strcasestr() might\nbe simpler. Could folks with access to Solaris boxes of\ndifferent vintages please see if the attached patch makes sense?\n\nCan we also unify UNSETENV, SETENV, C99_FORMAT and STRTOUMAX, by\nthe way? \n\n\ndiff --git a/Makefile b/Makefile\nindex e830bc7..cabde81 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -412,26 +412,25 @@ endif\n ifeq ($(uname_S),SunOS)\n \tNEEDS_SOCKET = YesPlease\n \tNEEDS_NSL = YesPlease\n \tSHELL_PATH = /bin/bash\n \tNO_STRCASESTR = YesPlease\n \tNO_MEMMEM = YesPlease\n \tNO_HSTRERROR = YesPlease\n+\tNO_MKDTEMP = YesPlease\n \tifeq ($(uname_R),5.8)\n \t\tNEEDS_LIBICONV = YesPlease\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n-\t\tNO_MKDTEMP = YesPlease\n \t\tNO_C99_FORMAT = YesPlease\n \t\tNO_STRTOUMAX = YesPlease\n \tendif\n \tifeq ($(uname_R),5.9)\n \t\tNO_UNSETENV = YesPlease\n \t\tNO_SETENV = YesPlease\n-\t\tNO_MKDTEMP = YesPlease\n \t\tNO_C99_FORMAT = YesPlease\n \t\tNO_STRTOUMAX = YesPlease\n \tendif\n \tINSTALL = ginstall\n \tTAR = gtar\n \tBASIC_CFLAGS += -D__EXTENSIONS__\n endif\n"},{"id":"60231","messageId":"Pine.LNX.4.64.0711181302360.3945@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7vtznlww0t.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [RFH] Solaris portability","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-18T12:08:20Z","receivedAt":"2007-11-18T12:08:20Z","isPatch":false,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"On Fri, 16 Nov 2007, Junio C Hamano wrote:\n> This makes me wonder if treating it just like strcasestr() might be \n> simpler. Could folks with access to Solaris boxes of different vintages \n> please see if the attached patch makes sense?\n\nI think the patch makes sense as neither Solaris 8, 9 nor 10 supports \nmkdtemp().\n\n> Can we also unify UNSETENV, SETENV, C99_FORMAT and STRTOUMAX, by the \n> way?\n\nNo.\n\nI've just checked on our Solaris Sparc systems, and found that the \nC-library provides unsetenv(), setenv() and strtoumax() beginning with \nSolaris 10; also the 'man sprintf' page mentions the 'z' and 't' \nspecifiers for printf (which is what is behind C99_FORMAT) only beginning \nwith Solaris 10.\n\nSo workarounds are needed for all 4 cases for Solaris 8 and 9 but not 10.\n\nRegards\n\nGuido\n"},{"id":"60240","messageId":"7vmytbwins.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711181302360.3945@bianca.dialin.t-online.de","subject":"Re: [RFH] Solaris portability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-18T17:46:47Z","receivedAt":"2007-11-18T17:46:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Guido Ostkamp writes:\n\n> On Fri, 16 Nov 2007, Junio C Hamano wrote:\n>> This makes me wonder if treating it just like strcasestr() might be\n>> simpler. Could folks with access to Solaris boxes of different\n>> vintages please see if the attached patch makes sense?\n>\n> I think the patch makes sense as neither Solaris 8, 9 nor 10 supports\n> mkdtemp().\n>\n>> Can we also unify UNSETENV, SETENV, C99_FORMAT and STRTOUMAX, by the\n>> way?\n>\n> No.\n>\n> I've just checked on our Solaris Sparc systems, and found that the\n> C-library provides unsetenv(), setenv() and strtoumax() beginning with\n> Solaris 10; also the 'man sprintf' page mentions the 'z' and 't'\n> specifiers for printf (which is what is behind C99_FORMAT) only\n> beginning with Solaris 10.\n>\n> So workarounds are needed for all 4 cases for Solaris 8 and 9 but not 10.\n\nThank you very much for detailed information.\n"},{"id":"60341","messageId":"Pine.LNX.4.64.0711191847550.7957@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7vd4ua3hww.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-19T17:51:00Z","receivedAt":"2007-11-19T17:51:00Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"Hello Junio,\n\nOn Thu, 15 Nov 2007, Junio C Hamano wrote:\n> As I suspect there are other compilers that do not implement flexible \n> array members (so you cannot use \"member[]\") nor older gcc extension of \n> zero sized member (so you cannot use \"member[0]\" either), this checking \n> specifically for Sun is too narrow.\n>\n> On the other hand, as you said, this is too broad, because not everybody \n> may be using the SUN compiler on Sun, nor the version that does not \n> understand flexible array members.\n>\n> But being broad should always be safer, albeit a bit wasteful.\n>\n> How about doing it this way?\n\nit looks ok on Solaris. I assembled the following patch from your posting, \ncould you please include it?\n\n\nSigned-off-by: Guido Ostkamp \n---\n git-compat-util.h | 11 ++++++++++-\n 1 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 276a437..97759fd 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -4,11 +4,20 @@\n #define _FILE_OFFSET_BITS 64\n\n #ifndef FLEX_ARRAY\n-#if defined(__GNUC__) && (__GNUC__ < 3)\n+#if defined(__GNUC__)\n+#if (__GNUC__ < 3)\n #define FLEX_ARRAY 0\n #else\n #define FLEX_ARRAY /* empty */\n #endif\n+#else\n+/* more cases we know we can use 0 or empty can come here */\n+#endif\n+#endif\n+\n+/* if still undefined, default to the safe, old fashioned way */\n+#ifndef FLEX_ARRAY\n+#define FLEX_ARRAY 1\n #endif\n\n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n-- \n1.5.3.6.728.gea559\n"},{"id":"60396","messageId":"7vhcjhl3ni.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711191847550.7957@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-20T08:30:57Z","receivedAt":"2007-11-20T08:30:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Guido Ostkamp writes:\n\n>> ...\n>> How about doing it this way?\n>\n> it looks ok on Solaris. I assembled the following patch from your\n> posting, could you please include it?\n>\n>\n> Signed-off-by: Guido Ostkamp \n\nI knew it would work on Solaris with gcc and cc that do not\nunderstand flexible array members, but I am a bit worried about\nother environments, where flexible array members are properly\nsupported. They've been happily using member[] but with the\npatch they suddenly start wasting a cell.\n\nBut we should do this sooner rather than later to find out any\nbreakage, and give people on platforms with a cc that supports\nflexible array members and care about wasted memory enough time\nto send patches to support their compiler in the way similar to\nhow gcc is supported.\n\nBut I cannot use your message with whitespace-broken patch (note\n\"format=flawed\") and insufficient commit log message, which\nmeans I have to do this myself. Not tonight...\n"},{"id":"60414","messageId":"Pine.LNX.4.64.0711201823460.4280@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"7vhcjhl3ni.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-20T17:28:39Z","receivedAt":"2007-11-20T17:28:39Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"Hello Junio,\n\nOn Tue, 20 Nov 2007, Junio C Hamano wrote:\n> I knew it would work on Solaris with gcc and cc that do not understand \n> flexible array members, but I am a bit worried about other environments, \n> where flexible array members are properly supported. They've been \n> happily using member[] but with the patch they suddenly start wasting a \n> cell.\n>\n> But we should do this sooner rather than later to find out any breakage, \n> and give people on platforms with a cc that supports flexible array \n> members and care about wasted memory enough time to send patches to \n> support their compiler in the way similar to how gcc is supported.\n>\n> But I cannot use your message with whitespace-broken patch (note \n> \"format=flawed\") and insufficient commit log message, which means I have \n> to do this myself. Not tonight...\n\nsorry for the whitespace-issues. I have attached the patch again with \nimproved log message and will turn off format-flawed for this email.\n\nPlease let me know if this one is ok and feel free to fix it.\n\nLog message starts here:\n\nFix \"identifier redeclared\" compilation error with SUN cc.\n\nThe problem is caused by incomplete arrays like\n\n struct foo {\n ...\n char last_member_that_is_flexible[];\n }\n\nwhich cannot be handled by certain compilers.\nThe solution is to change the last member to either\n\n char last_member_that_is_flexible[0]\n\nor\n\n char last_member_that_is_flexible[1]\n\nas required. Currently GNU CC can handle [] format for \nversion 3 and later. Earlier versions need [0].\nNon-GNU compiler use the safe form [1].\n\nSigned-off-by: Guido Ostkamp \n---\n git-compat-util.h | 11 ++++++++++-\n 1 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 276a437..97759fd 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -4,11 +4,20 @@\n #define _FILE_OFFSET_BITS 64\n\n #ifndef FLEX_ARRAY\n-#if defined(__GNUC__) && (__GNUC__ < 3)\n+#if defined(__GNUC__)\n+#if (__GNUC__ < 3)\n #define FLEX_ARRAY 0\n #else\n #define FLEX_ARRAY /* empty */\n #endif\n+#else\n+/* more cases we know we can use 0 or empty can come here */\n+#endif\n+#endif\n+\n+/* if still undefined, default to the safe, old fashioned way */\n+#ifndef FLEX_ARRAY\n+#define FLEX_ARRAY 1\n #endif\n\n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n-- \n1.5.3.6.728.gea559\n"},{"id":"60417","messageId":"Pine.LNX.4.64.0711201901280.4732@bianca.dialin.t-online.de","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711201823460.4280@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Guido Ostkamp","fromEmail":"git@ostkamp.fastmail.fm","sentAt":"2007-11-20T18:06:44Z","receivedAt":"2007-11-20T18:06:44Z","isPatch":true,"sender":{"key":"git@ostkamp.fastmail.fm","avatar":null},"body":"> sorry for the whitespace-issues. I have attached the patch again with \n> improved log message and will turn off format-flawed for this email.\n\nonly for the list: I noticed another whitespace problem and have meanwhile \nsent the patch to Junio as true attachment of a private email because I do \nnot know whether attachments are accepted on this list (most likely they \nare not). Sorry for the inconvenience.\n\nRegards\n\nGuido\n"},{"id":"60428","messageId":"mj+md-20071120.182204.515.nikam@ucw.cz","threadId":"10870","inReplyTo":"Pine.LNX.4.64.0711191847550.7957@bianca.dialin.t-online.de","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2007-11-20T18:26:15Z","receivedAt":"2007-11-20T18:26:15Z","isPatch":true,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hello!\n\n> #ifndef FLEX_ARRAY\n> -#if defined(__GNUC__) && (__GNUC__ < 3)\n> +#if defined(__GNUC__)\n> +#if (__GNUC__ < 3)\n> #define FLEX_ARRAY 0\n> #else\n> #define FLEX_ARRAY /* empty */\n> #endif\n> +#else\n> +/* more cases we know we can use 0 or empty can come here */\n> +#endif\n> +#endif\n> +\n> +/* if still undefined, default to the safe, old fashioned way */\n> +#ifndef FLEX_ARRAY\n> +#define FLEX_ARRAY 1\n> #endif\n\nDo we really want to use empty FLEX_ARRAY only for a new gcc? Shouldn't\nwe test for C99 instead (__STDC_VERSION__ >= 199901L) and only if it\nisn't C99, choose between 0 and 1 depending on gccness of the compiler?\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://mj.ucw.cz/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\n\"First they ignore you. Then they laugh at you. Then they fight you. Then you win.\" -- Gandhi\n"},{"id":"60436","messageId":"7vzlx8k7dl.fsf@gitster.siamese.dyndns.org","threadId":"10870","inReplyTo":"mj+md-20071120.182204.515.nikam@ucw.cz","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-20T20:08:06Z","receivedAt":"2007-11-20T20:08:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Mares writes:\n\n> Do we really want to use empty FLEX_ARRAY only for a new gcc? Shouldn't\n> we test for C99 instead (__STDC_VERSION__ >= 199901L) and only if it\n> isn't C99, choose between 0 and 1 depending on gccness of the compiler?\n\nHow about doing it this way?\n\n-- >8 --\n[PATCH] git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY a bit better\n\nWhen declaring a structure with a flexible array member, instead\nof defaulting to the c99 syntax for non-gnu compilers (which\nburned people with older compilers), default to the traditional\nand more portable \"member[1]; /* more */\" syntax.\n\nAt the same time, other c99 compilers should be able to take\nadvantage of the modern syntax to flexible array members without\nbeing gcc. Check __STDC_VERSION__ for that.\n\nSigned-off-by: Junio C Hamano \n---\n git-compat-util.h | 22 ++++++++++++++++++----\n 1 files changed, 18 insertions(+), 4 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 276a437..454d25e 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -4,10 +4,24 @@\n #define _FILE_OFFSET_BITS 64\n \n #ifndef FLEX_ARRAY\n-#if defined(__GNUC__) && (__GNUC__ < 3)\n-#define FLEX_ARRAY 0\n-#else\n-#define FLEX_ARRAY /* empty */\n+/*\n+ * See if our compiler is known to support flexible array members.\n+ */\n+#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)\n+# define FLEX_ARRAY /* empty */\n+#elif defined(__GNUC__)\n+# if (__GNUC__ >= 3)\n+# define FLEX_ARRAY /* empty */\n+# else\n+# define FLEX_ARRAY 0 /* older GNU extension */\n+# endif\n+#endif\n+\n+/*\n+ * Otherwise, default to safer but a bit wasteful traditional style\n+ */\n+#ifndef FLEX_ARRAY\n+# define FLEX_ARRAY 1\n #endif\n #endif\n \n-- \n1.5.3.6.1797.g67f5d\n"},{"id":"60437","messageId":"mj+md-20071120.200931.23805.nikam@ucw.cz","threadId":"10870","inReplyTo":"7vzlx8k7dl.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix \"identifier redeclared\" compilation error with SUN cc","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2007-11-20T20:09:41Z","receivedAt":"2007-11-20T20:09:41Z","isPatch":true,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hello!\n\n> How about doing it this way?\n\nYes, this looks perfect.\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://mj.ucw.cz/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\nHi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!\n"}]}