{"thread":{"id":"63123","subject":"[PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","startedAt":"2025-03-15T02:47:48Z","lastAt":"2025-03-17T20:46:56Z","messageCount":5,"participants":["Ramsay Jones","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":12},"messages":[{"id":"514336","messageId":"a4272c4a-7073-4671-a883-50e9413b0384@ramsayjones.plus.com","threadId":"63123","inReplyTo":null,"subject":"[PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-15T02:47:44Z","receivedAt":"2025-03-15T02:47:48Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nCommit 92f63d2b05 (\"Cygwin 1.7 needs compat/regex\", 2013-07-19) set\nthe NO_REGEX build variable because the platform regex library failed\nsome of the tests (t4018 and t4034), which passed just fine with the\ncompat library.\n\nAfter some time (may a year or two), the platform library had been\nupdated (with an import from FreeBSD, I believe) and now passed the full\ntest-suite. This would be about the time of the v1.7 -> v2.0 transition\nin 2015. I had a patch ready to send, but just didn't get around to\nsubmitting it to the list. At some point in the interim, the official\ncygwin git package used the autoconf build system, which sets the\nNO_REGEX variable to use the platform regex library functions. The new\nmeson build system does likewise.\n\nIn order to produce the same NO_REGEX configuration from autoconf, meson\nand make, modify config.mak.uname to only set NO_REGEX for cygwin v1.7.\n\nSigned-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>\n---\n config.mak.uname | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/config.mak.uname b/config.mak.uname\nindex ae6ba15586..b6adce0bc4 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -245,7 +245,9 @@ ifeq ($(uname_O),Cygwin)\n \t\t# Try commenting this out if you suspect MMAP is more efficient\n \t\tNO_MMAP = YesPlease\n         else\n-\t\tNO_REGEX = UnfortunatelyYes\n+                ifeq ($(shell expr \"$(uname_R)\" : '1\\.7\\.'),4)\n+\t\t        NO_REGEX = UnfortunatelyYes\n+                endif\n         endif\n \tHAVE_DEV_TTY = YesPlease\n \tHAVE_ALLOCA_H = YesPlease\n-- \n2.49.0\n"},{"id":"514403","messageId":"33561996-3b7f-4d0e-825f-5b2369d7d010@ramsayjones.plus.com","threadId":"63123","inReplyTo":"a4272c4a-7073-4671-a883-50e9413b0384@ramsayjones.plus.com","subject":"Re: [PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-16T22:24:18Z","receivedAt":"2025-03-16T22:24:21Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 15/03/2025 02:47, Ramsay Jones wrote:\n> \n> Commit 92f63d2b05 (\"Cygwin 1.7 needs compat/regex\", 2013-07-19) set\n> the NO_REGEX build variable because the platform regex library failed\n> some of the tests (t4018 and t4034), which passed just fine with the\n> compat library.\n> \n> After some time (may a year or two), the platform library had been\n> updated (with an import from FreeBSD, I believe) and now passed the full\n> test-suite. This would be about the time of the v1.7 -> v2.0 transition\n> in 2015. I had a patch ready to send, but just didn't get around to\n> submitting it to the list.\n\nI forgot to mention, that one of the reasons that I didn't get around\nto submitting this patch then, was because of a '# TODO known breakage\nvanished' in test t7815-grep-binary.sh:\n\n  $ ./t7815-grep-binary.sh\n  ok 1 - setup\n  ok 2 - git grep ina a\n  ok 3 - git grep -ah ina a\n  ok 4 - git grep -I ina a\n  ok 5 - git grep -c ina a\n  ok 6 - git grep -l ina a\n  ok 7 - git grep -L bar a\n  ok 8 - git grep -q ina a\n  ok 9 - git grep -F ile a\n  ok 10 - git grep -Fi iLE a\n  ok 11 - git grep ile a\n  ok 12 - git grep .fi a # TODO known breakage vanished\n  ok 13 - grep respects binary diff attribute\n  ok 14 - grep --cached respects binary diff attribute\n  ok 15 - grep --cached respects binary diff attribute (2)\n  ok 16 - grep revision respects binary diff attribute\n  ok 17 - grep respects not-binary diff attribute\n  ok 18 - setup textconv filters\n  ok 19 - grep does not honor textconv\n  ok 20 - grep --textconv honors textconv\n  ok 21 - grep --no-textconv does not honor textconv\n  ok 22 - grep --textconv blob honors textconv\n  # 1 known breakage(s) vanished; please update test(s)\n  # passed all remaining 21 test(s)\n  1..22\n  $ \n\nThe platform regex library is happy to match a NUL byte with the '.'\npattern. (presumably this is also true on FreeBSD?).\n\nI could not decide on the best way to 'fix' this issue. The options\nseemed to be: do nothing (it's not hurting anyone), disable the test\non cygwin or simply remove the test.\n\n[I think I prefer to simply delete the test, since it doesn't seem to\nbe testing anything useful, as far as I can see.]\n\nWhat do you think?\n\nATB,\nRamsay Jones\n\n\n"},{"id":"514411","messageId":"xmqqh63rbqla.fsf@gitster.g","threadId":"63123","inReplyTo":"33561996-3b7f-4d0e-825f-5b2369d7d010@ramsayjones.plus.com","subject":"Re: [PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-17T15:54:09Z","receivedAt":"2025-03-17T15:54:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n\n>> After some time (may a year or two), the platform library had been\n>> updated (with an import from FreeBSD, I believe) and now passed the full\n>> test-suite. This would be about the time of the v1.7 -> v2.0 transition\n>> in 2015. I had a patch ready to send, but just didn't get around to\n>> submitting it to the list.\n\nSo is it safe for us to just drop the bit that sets NO_REGEX and\nrequire Cygwin that is less than 10 years old?  As long as people\nare willing to actively maintain the compatibility wart for older\nsystems there is no strong reason to do so, but at some point it\nwould become diminishing returns even for those who have hardware to\ndevelop, build, and test on, when the reason they keep such an old\nsystem becomes only to maintain it instead of actively using it,\nand I am wondering if Cygwin 1.7 has past that point.\n\n> I forgot to mention, that one of the reasons that I didn't get around\n> to submitting this patch then, was because of a '# TODO known breakage\n> vanished' in test t7815-grep-binary.sh:\n> ...\n> The platform regex library is happy to match a NUL byte with the '.'\n> pattern. (presumably this is also true on FreeBSD?).\n\nIn this test, the haystack has \"binary\\0file\\0m...\" and the needle\nto be sought is \".fi\".  The system I have at hand uses glibc 2.40\nand it refuses to match NUL with '.', it seems.\n\n> I could not decide on the best way to 'fix' this issue. The options\n> seemed to be: do nothing (it's not hurting anyone), disable the test\n> on cygwin or simply remove the test.\n\nThe part \"On Cygwin\" somewhat puzzled me; aren't folks on various\nBSD variants seeing the same symptom?\n\nDo we want to eventually turn it to test_expect_success?  I think\nthe \"fix\" depends on this single question, and I am not sure if we\ndo.\n\nIs the behaviour that '.' matches NUL on some platform and doesn't\non some others hurting anybody?  I dislike a tool that behaves\ndifferently depending on the platform, but not strongly enough in\nthis case somehow.\n\nOn the same system, GNU grep and sed seem to consider that '.'\nmatches NUL there, i.e.\n\n    $ grep -a '.fi' a | cat -v -T\n    binary^@file^@m[*]c^@*M-CM-&^@M-CM-0\n    $ sed -n -e '/.fi/p' a | cat -v -T\n\n\n> [I think I prefer to simply delete the test, since it doesn't seem to\n> be testing anything useful, as far as I can see.]\n>\n> What do you think?\n>\n> ATB,\n> Ramsay Jones\n"},{"id":"514412","messageId":"xmqqecyvbqhn.fsf@gitster.g","threadId":"63123","inReplyTo":"33561996-3b7f-4d0e-825f-5b2369d7d010@ramsayjones.plus.com","subject":"Re: [PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-17T15:56:20Z","receivedAt":"2025-03-17T15:56:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n\n>> After some time (may a year or two), the platform library had been\n>> updated (with an import from FreeBSD, I believe) and now passed the full\n>> test-suite. This would be about the time of the v1.7 -> v2.0 transition\n>> in 2015. I had a patch ready to send, but just didn't get around to\n>> submitting it to the list.\n\nSo is it safe for us to just drop the bit that sets NO_REGEX and\nrequire Cygwin that is less than 10 years old?  As long as people\nare willing to actively maintain the compatibility wart for older\nsystems there is no strong reason to do so, but at some point it\nwould become diminishing returns even for those who have hardware to\ndevelop, build, and test on, when the reason they keep such an old\nsystem becomes only to maintain it instead of actively using it,\nand I am wondering if Cygwin 1.7 has past that point.\n\n> I forgot to mention, that one of the reasons that I didn't get around\n> to submitting this patch then, was because of a '# TODO known breakage\n> vanished' in test t7815-grep-binary.sh:\n> ...\n> The platform regex library is happy to match a NUL byte with the '.'\n> pattern. (presumably this is also true on FreeBSD?).\n\nIn this test, the haystack has \"binary\\0file\\0m...\" and the needle\nto be sought is \".fi\".  The system I have at hand uses glibc 2.40\nand it refuses to match NUL with '.', it seems.\n\n> I could not decide on the best way to 'fix' this issue. The options\n> seemed to be: do nothing (it's not hurting anyone), disable the test\n> on cygwin or simply remove the test.\n\nThe part \"On Cygwin\" somewhat puzzled me; aren't folks on various\nBSD variants seeing the same symptom?\n\nDo we want to eventually turn it to test_expect_success?  I think\nthe \"fix\" depends on this single question, and I am not sure if we\ndo.\n\nIs the behaviour that '.' matches NUL on some platform and doesn't\non some others hurting anybody?  I dislike a tool that behaves\ndifferently depending on the platform, but not strongly enough in\nthis case somehow.\n\nOn the same system, GNU grep and sed seem to consider that '.'\nmatches NUL there, i.e.\n\n    $ grep -a '.fi' a | cat -v -T\n    binary^@file^@m[*]c^@*M-CM-&^@M-CM-0\n    $ sed -n -e '/.fi/p' a | cat -v -T\n    binary^@file^@m[*]c^@*M-CM-&^@M-CM-0\n\nThey ought to be using the same library as Git compiled on this\nsystem does, so it is somewhat curious.\n\n> [I think I prefer to simply delete the test, since it doesn't seem to\n> be testing anything useful, as far as I can see.]\n>\n> What do you think?\n>\n> ATB,\n> Ramsay Jones\n"},{"id":"514433","messageId":"13ab486c-45b8-4dc4-885b-55db17c4641e@ramsayjones.plus.com","threadId":"63123","inReplyTo":"xmqqecyvbqhn.fsf@gitster.g","subject":"Re: [PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-17T20:43:45Z","receivedAt":"2025-03-17T20:46:56Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 17/03/2025 15:56, Junio C Hamano wrote:\n> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n> \n>>> After some time (may a year or two), the platform library had been\n>>> updated (with an import from FreeBSD, I believe) and now passed the full\n>>> test-suite. This would be about the time of the v1.7 -> v2.0 transition\n>>> in 2015. I had a patch ready to send, but just didn't get around to\n>>> submitting it to the list.\n> \n> So is it safe for us to just drop the bit that sets NO_REGEX and\n> require Cygwin that is less than 10 years old?  As long as people\n> are willing to actively maintain the compatibility wart for older\n> systems there is no strong reason to do so, but at some point it\n> would become diminishing returns even for those who have hardware to\n> develop, build, and test on, when the reason they keep such an old\n> system becomes only to maintain it instead of actively using it,\n> and I am wondering if Cygwin 1.7 has past that point.\n\nHeh, I have a patch (without a commit message) which I had intended\nto add at the very end, so that it is easy to drop, that looks like:\n\n  diff --git a/config.mak.uname b/config.mak.uname\n  index 1a897bd022..1dc69fc65b 100644\n  --- a/config.mak.uname\n  +++ b/config.mak.uname\n  @@ -235,22 +235,6 @@ ifeq ($(uname_S),SunOS)\n   \tBASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__\n   endif\n   ifeq ($(uname_O),Cygwin)\n  -        ifeq ($(shell expr \"$(uname_R)\" : '1\\.[1-6]\\.'),4)\n  -\t\tNO_D_TYPE_IN_DIRENT = YesPlease\n  -\t\tNO_STRCASESTR = YesPlease\n  -\t\tNO_MEMMEM = YesPlease\n  -\t\tNO_SYMLINK_HEAD = YesPlease\n  -\t\tNO_IPV6 = YesPlease\n  -\t\tOLD_ICONV = UnfortunatelyYes\n  -\t\t# There are conflicting reports about this.\n  -\t\t# On some boxes NO_MMAP is needed, and not so elsewhere.\n  -\t\t# Try commenting this out if you suspect MMAP is more efficient\n  -\t\tNO_MMAP = YesPlease\n  -        else\n  -                ifeq ($(shell expr \"$(uname_R)\" : '1\\.7\\.'),4)\n  -\t\t        NO_REGEX = UnfortunatelyYes\n  -                endif\n  -        endif\n   \tHAVE_DEV_TTY = YesPlease\n   \tHAVE_GETDELIM = YesPlease\n   \tHAVE_CLOCK_GETTIME=YesPlease\n\nThis would effectively drop 'support' for cygwin versions less than\nthe v2.0 (which was tagged on 27-apr-2015). Note that I don't know\nif it is possible to build git from source on those versions, even\nwith that conditional intact, but I guess it's more likely!\n\nGiven that it is unlikely to be me fielding the complaints from the\ncygwin git community, I wanted Adam (cygwin git maintainer) to\nprovide his input into the decision to incorporate such a patch. :)\n\n[I doubt there are many people building git from source on a very old\nversion of cygwin, but I just don't know! ;) ]\n\nI have been building (and running) git from source since about 2006,\non both Linux and cygwin, but I suspect that the vast majority of\ncygwin users just install Adam's package.\n\n>> I forgot to mention, that one of the reasons that I didn't get around\n>> to submitting this patch then, was because of a '# TODO known breakage\n>> vanished' in test t7815-grep-binary.sh:\n>> ...\n>> The platform regex library is happy to match a NUL byte with the '.'\n>> pattern. (presumably this is also true on FreeBSD?).\n> \n> In this test, the haystack has \"binary\\0file\\0m...\" and the needle\n> to be sought is \".fi\".  The system I have at hand uses glibc 2.40\n> and it refuses to match NUL with '.', it seems.\n> \n>> I could not decide on the best way to 'fix' this issue. The options\n>> seemed to be: do nothing (it's not hurting anyone), disable the test\n>> on cygwin or simply remove the test.\n> \n> The part \"On Cygwin\" somewhat puzzled me; aren't folks on various\n> BSD variants seeing the same symptom?\n\nAgain 'I don't know what I don't know'. :) I would have thought that\n(at least) FreeBSD users should also be seeing this 'known breakage\nvanished' issue, but we have not heard about it, so ... we *know*\nthat cygwin has this issue, hence the suggestion to disable the\ntest there.\n\n[Also, it is possible that either cygwin or FreeBSD changed the\nimplementation after the import.]\n\nThanks.\n\nATB,\nRamsay Jones\n\n\n"}]}