{"thread":{"id":"25038","subject":"NO_REGEX defaults on obscure platforms","startedAt":"2010-09-08T15:12:35Z","lastAt":"2010-09-10T00:10:48Z","messageCount":6,"participants":["Ævar Arnfjörð Bjarmason","Brandon Casey","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150302","messageId":"AANLkTimYY_KHwqWWXTxFqW67FHYtJJkLuA-6WVc6wzO5@mail.gmail.com","threadId":"25038","inReplyTo":null,"subject":"NO_REGEX defaults on obscure platforms","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-08T15:12:35Z","receivedAt":"2010-09-08T15:12:35Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Sep 6, 2010 at 07:41, Junio C Hamano wrote:\n\n> There are a few leftover bits in 'next' that need to be merged to 'master'\n> before we declare a real -rc cycle, so tonight's pushout is -rc0.\n\nOne thing that's almost certainly wrong in v1.7.3-rc0 is the NO_REGEX\ndefaults. It's a non-issue for people who run the configure script,\nbut the Makefile probably has the wrong defaults on some obscure\nplatforms.\n\nI've CC'd people involved in Tru64, UnixWare, SCO, HP/UX, IRIX etc. It\nwould be really useful if you could:\n\n 1. Get v1.7.3-rc0\n 2. Compile with the defaults, and NO_REGEX=YesPlease\n 3. Run `cd t && ./t7008-grep-binary.sh` and report the results.\n\nThat test is probably failing on some of these platforms.\n\nAlternatively, just check for REG_STARTEND in regex.h (or the includes\nit pulls in):\n\n $ grep REG_STARTEND /usr/include/regex.h\n #define REG_STARTEND (1 << 2)\n"},{"id":"150305","messageId":"HYj6Cf-QUJiUlQ7fPRq5qJw3IurvsqhLa1qIg9c6ajPY6g_B2-OehA@cipher.nrlssc.navy.mil","threadId":"25038","inReplyTo":"AANLkTimYY_KHwqWWXTxFqW67FHYtJJkLuA-6WVc6wzO5@mail.gmail.com","subject":"Re: NO_REGEX defaults on obscure platforms","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2010-09-08T15:31:44Z","receivedAt":"2010-09-08T15:31:44Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"On 09/08/2010 10:12 AM, Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Sep 6, 2010 at 07:41, Junio C Hamano wrote:\n> \n>> There are a few leftover bits in 'next' that need to be merged to 'master'\n>> before we declare a real -rc cycle, so tonight's pushout is -rc0.\n> \n> One thing that's almost certainly wrong in v1.7.3-rc0 is the NO_REGEX\n> defaults. It's a non-issue for people who run the configure script,\n> but the Makefile probably has the wrong defaults on some obscure\n> platforms.\n> \n> I've CC'd people involved in Tru64, UnixWare, SCO, HP/UX, IRIX etc. It\n> would be really useful if you could:\n> \n> 1. Get v1.7.3-rc0\n> 2. Compile with the defaults, and NO_REGEX=YesPlease\n> 3. Run `cd t && ./t7008-grep-binary.sh` and report the results.\n> \n> That test is probably failing on some of these platforms.\n\nYes, I've already tested and IRIX does indeed need to use the compat\nregex, i.e. IRIX needs NO_REGEX=YesPlease.\n\n> Alternatively, just check for REG_STARTEND in regex.h (or the includes\n> it pulls in):\n> \n> $ grep REG_STARTEND /usr/include/regex.h\n> #define REG_STARTEND (1 << 2)\n\nUnfortunately, IRIX actually defines REG_STARTEND in its regex.h, but\nthe feature does not seem to work. This also means the configure script\nwill give a false negative and indicate that NO_REGEX should _not_ be\nset, when it actually should be.\n\nI have a few other patches, in addition to this NO_REGEX setting, that\nI haven't found time to submit, but my feelings won't be hurt if someone\nelse beats me to it. (hint, hint :)\n\n-Brandon\n"},{"id":"150311","messageId":"m3hbi0m9uw.fsf@localhost.localdomain","threadId":"25038","inReplyTo":"HYj6Cf-QUJiUlQ7fPRq5qJw3IurvsqhLa1qIg9c6ajPY6g_B2-OehA@cipher.nrlssc.navy.mil","subject":"Re: NO_REGEX defaults on obscure platforms","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-08T17:20:08Z","receivedAt":"2010-09-08T17:20:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brandon Casey writes:\n> On 09/08/2010 10:12 AM, Ævar Arnfjörð Bjarmason wrote:\n>> On Mon, Sep 6, 2010 at 07:41, Junio C Hamano wrote:\n>> \n>>> There are a few leftover bits in 'next' that need to be merged to 'master'\n>>> before we declare a real -rc cycle, so tonight's pushout is -rc0.\n>> \n>> One thing that's almost certainly wrong in v1.7.3-rc0 is the NO_REGEX\n>> defaults. It's a non-issue for people who run the configure script,\n>> but the Makefile probably has the wrong defaults on some obscure\n>> platforms.\n[...]\n\n>> Alternatively, just check for REG_STARTEND in regex.h (or the includes\n>> it pulls in):\n>> \n>> $ grep REG_STARTEND /usr/include/regex.h\n>> #define REG_STARTEND (1 << 2)\n> \n> Unfortunately, IRIX actually defines REG_STARTEND in its regex.h, but\n> the feature does not seem to work. This also means the configure script\n> will give a false negative and indicate that NO_REGEX should _not_ be\n> set, when it actually should be.\n\nWell, that just means that the test for NO_REGEX in configure.ac\nshould be more involved than just checking if REG_STARTEND is defined:\nit should test if regex can truly handle null bytes. There are some\nexamples of such test programs: see e.g. check for NO_C99_FORMAT\nabove.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"150395","messageId":"aIkKF4vjSeghwDQ63eyGAtU7mB-u0vNW0EzVfr5b9bck9XbQlHqCr65xFtnqEeEN20sMaBebsFc@cipher.nrlssc.navy.mil","threadId":"25038","inReplyTo":"HYj6Cf-QUJiUlQ7fPRq5qJw3IurvsqhLa1qIg9c6ajPY6g_B2-OehA@cipher.nrlssc.navy.mil","subject":"[PATCH 1/2] t/t7008: workaround broken handling of \\000 by printf on IRIX","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2010-09-09T19:15:57Z","receivedAt":"2010-09-09T19:15:57Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"From: Brandon Casey \n\nOn IRIX 6.5, the printf utility in /usr/bin does not appear to handle the\n\\ddd notation according to POSIX. This printf appears to halt processing\nof the string argument and ignore any additional characters in the string.\nWork around this flaw by replacing the \\000's with 'Q' and using the\nq_to_nul helper function provided by test-lib.sh\n\nThis problem with printf is not apparent when using the Bash shell since\nBash implements a POSIX compatible printf function internally.\n\nSigned-off-by: Brandon Casey \n---\n t/t7008-grep-binary.sh | 14 +++++++-------\n 1 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/t/t7008-grep-binary.sh b/t/t7008-grep-binary.sh\nindex c0f9f3f..e058d18 100755\n--- a/t/t7008-grep-binary.sh\n+++ b/t/t7008-grep-binary.sh\n@@ -5,7 +5,7 @@ test_description='git grep in binary files'\n . ./test-lib.sh\n \n test_expect_success 'setup' \"\n-\tprintf 'binary\\000file\\n' >a &&\n+\techo 'binaryQfile' | q_to_nul >a &&\n \tgit add a &&\n \tgit commit -m.\n \"\n@@ -70,32 +70,32 @@ test_expect_failure 'git grep .fi a' '\n '\n \n test_expect_success 'git grep -F yf a' \"\n-\tprintf 'y\\000f' >f &&\n+\tprintf 'yQf' | q_to_nul >f &&\n \tgit grep -f f -F a\n \"\n \n test_expect_success 'git grep -F yx a' \"\n-\tprintf 'y\\000x' >f &&\n+\tprintf 'yQx' | q_to_nul >f &&\n \ttest_must_fail git grep -f f -F a\n \"\n \n test_expect_success 'git grep -Fi Yf a' \"\n-\tprintf 'Y\\000f' >f &&\n+\tprintf 'YQf' | q_to_nul >f &&\n \tgit grep -f f -Fi a\n \"\n \n test_expect_failure 'git grep -Fi Yx a' \"\n-\tprintf 'Y\\000x' >f &&\n+\tprintf 'YQx' | q_to_nul >f &&\n \ttest_must_fail git grep -f f -Fi a\n \"\n \n test_expect_success 'git grep yf a' \"\n-\tprintf 'y\\000f' >f &&\n+\tprintf 'yQf' | q_to_nul >f &&\n \tgit grep -f f a\n \"\n \n test_expect_failure 'git grep yx a' \"\n-\tprintf 'y\\000x' >f &&\n+\tprintf 'yQx' | q_to_nul >f &&\n \ttest_must_fail git grep -f f a\n \"\n \n-- \n1.7.2.1\n"},{"id":"150394","messageId":"aIkKF4vjSeghwDQ63eyGAvzoq81HvE3fJPXM0HchsiJm2ahDUH-dO4jBA6nOEoyKGFpRKLAY7_A@cipher.nrlssc.navy.mil","threadId":"25038","inReplyTo":"HYj6Cf-QUJiUlQ7fPRq5qJw3IurvsqhLa1qIg9c6ajPY6g_B2-OehA@cipher.nrlssc.navy.mil","subject":"[PATCH 2/2] Makefile: use compat regex on IRIX 6.5","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2010-09-09T19:15:58Z","receivedAt":"2010-09-09T19:15:58Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"From: Brandon Casey \n\nThe IRIX 6.5 regex.h header file defines REG_STARTEND, but the feature does\nnot appear to work. Since REG_STARTEND is required for proper functioning\nof git-grep, set NO_REGEX and use the alternative regex libraries in compat/\n\nSigned-off-by: Brandon Casey \n---\n Makefile | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 8b7c243..c27e8bc 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -982,6 +982,7 @@ ifeq ($(uname_S),IRIX)\n \t# NO_MMAP. If you suspect that your compiler is not affected by this\n \t# issue, comment out the NO_MMAP statement.\n \tNO_MMAP = YesPlease\n+\tNO_REGEX = YesPlease\n \tSNPRINTF_RETURNS_BOGUS = YesPlease\n \tSHELL_PATH = /usr/gnu/bin/bash\n \tNEEDS_LIBGEN = YesPlease\n@@ -1000,6 +1001,7 @@ ifeq ($(uname_S),IRIX64)\n \t# NO_MMAP. If you suspect that your compiler is not affected by this\n \t# issue, comment out the NO_MMAP statement.\n \tNO_MMAP = YesPlease\n+\tNO_REGEX = YesPlease\n \tSNPRINTF_RETURNS_BOGUS = YesPlease\n \tSHELL_PATH=/usr/gnu/bin/bash\n \tNEEDS_LIBGEN = YesPlease\n-- \n1.7.2.1\n"},{"id":"150420","messageId":"7v39tilapj.fsf@alter.siamese.dyndns.org","threadId":"25038","inReplyTo":"aIkKF4vjSeghwDQ63eyGAvzoq81HvE3fJPXM0HchsiJm2ahDUH-dO4jBA6nOEoyKGFpRKLAY7_A@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] Makefile: use compat regex on IRIX 6.5","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-10T00:10:48Z","receivedAt":"2010-09-10T00:10:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks, as always.\n"}]}