{"thread":{"id":"44222","subject":"RE: [musl] Re: Regression: git no longer works with musl libc's regex impl","startedAt":"2016-10-05T03:06:06Z","lastAt":"2016-10-05T10:50:19Z","messageCount":2,"participants":["writeonce@midipix.org","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"303338","messageId":"20161004200057.dc30d64f61e5ec441c34ffd4f788e58e.efa66ead67.wbe@email15.godaddy.com","threadId":"44222","inReplyTo":null,"subject":"RE: [musl] Re: Regression: git no longer works with musl libc's regex impl","fromName":"","fromEmail":"writeonce@midipix.org","sentAt":"2016-10-05T03:00:57Z","receivedAt":"2016-10-05T03:06:06Z","isPatch":false,"sender":{"key":"writeonce@midipix.org","avatar":null},"body":"\n< \n< \n< -------- Original Message --------\n< Subject: [musl] Re: Regression: git no longer works with musl libc's\n< regex impl\n< From: Johannes Schindelin \n< Date: Tue, October 04, 2016 9:08 am\n< To: Rich Felker \n< Cc: Jeff King , git@vger.kernel.org,\n< musl@lists.openwall.com\n< \n< Hi Rich,\n< \n< On Tue, 4 Oct 2016, Rich Felker wrote:\n< \n< > On Tue, Oct 04, 2016 at 11:27:22AM -0400, Jeff King wrote:\n< > > On Tue, Oct 04, 2016 at 11:08:48AM -0400, Rich Felker wrote:\n< > > \n< > > > 1. is nonzero mod page size, it just works; the remainder of the\nlast\n< > > > page reads as zero bytes when mmapped.\n< > > \n< > > Is that a portable assumption?\n< > \n< > Yes.\n< \n< No, it is not. You quote POSIX, but the matter of the fact is that we\nuse\n< a subset of POSIX in order to be able to keep things running on\nWindows.\n< \n\nAs far as I can tell (and as the attached program may help demonstrate),\nthe above assumption has been valid on all versions of Windows since at\nleast Windows 2000. In this context, one thing to remember is that the\npage-size for the mod operation is 4096, whereas the POSIX page-size\n(for the purpose of mmap and mremap) is 65536. Note also that in the\ncase of file-backed mapped sections, using kernel32.dll or msvcrt.dll or\ncygwin/newlib or midipix/musl is of little significance, specifically\nsince all invoke ZwCreateSection and ZwMapViewOfSection under the hood.\n\nHTH,\nmidipix\n\n< And quite honestly, there are lots of reasons to keep things running\non\n< Windows, and even to favor Windows support over musl support. Over\nfour\n< million reasons: the Git for Windows users.\n< \n< So rather than getting into an ideological discussion about \"broken\"\n< systems, it would be good to keep things practical, realizing that\nthose\n< users make up a very real chunk of all of Git's users.\n< \n< As to making NO_REGEX conditional on REG_STARTEND: you are talking\nabout\n< apples and oranges here. NO_REGEX is a Makefile flag, while\nREG_STARTEND\n< is a C preprocessor macro.\n< \n< Unless you can convince the rest of the Git developers (you would not\n< convince me) to simulate autoconf by compiling an executable every\ntime\n< `make` is run, to determine whether REG_STARTEND is defined, this is a\n< no-go.\n< \n< However, you *can* use autoconf directly, and come up with a patch to\nour\n< configure.ac that detects the absence of REG_STARTEND and sets\nNO_REGEX=1.\n< \n< Alternatively, you can set NO_REGEX=1 in your config.mak.\n< \n< Or, if you use one of the auto-detected cases in config.mak.uname, you\n< could patch it to set NO_REGEX=1.\n< \n< And lastly, the best alternative would be to teach musl about\n< REG_STARTEND, as it is rather useful a feature.\n< \n< Ciao,\n< Johannes\n< \n\n\n\n#define _XOPEN_SOURCE 500\n#define NT_FILE_BACKED_PAGE_SIZE 4096\n\n#include \n#include \n#include \n#include \n#include \n\nstatic int test_file_backed_mmap(int size)\n{\n\tint fd;\n\tint exsize;\n\tvoid * addr;\n\tchar * test;\n\tchar * cap;\n\tchar name[12];\n\n\t/* create test file of desired size */\n\tsprintf(name,\"%d.tmp\",size);\n\n\tif ((fd = creat(name,0755)) < 0)\n\t\treturn -1;\n\n\tif (ftruncate(fd,size))\n\t\treturn -1;\n\n\tclose(fd);\n\n\t/* write 'W' to all bytes of test file */\n\tif ((fd = open(name,O_RDWR,0)) < 0)\n\t\treturn -1;\n\n\tif ((addr = mmap(0,size,PROT_WRITE,MAP_SHARED,fd,0)) == MAP_FAILED)\n\t\treturn -1;\n\n\tclose(fd);\n\n\ttest = (char *)addr;\n\tcap = (char *)addr + size;\n\n\tfor (; test < On Tue, 4 Oct 2016, Rich Felker wrote:\n> < \n> < > On Tue, Oct 04, 2016 at 11:27:22AM -0400, Jeff King wrote:\n> < > > On Tue, Oct 04, 2016 at 11:08:48AM -0400, Rich Felker wrote:\n> < > > \n> < > > > 1. is nonzero mod page size, it just works; the remainder of the\n> < > > > last page reads as zero bytes when mmapped.\n> < > > \n> < > > Is that a portable assumption?\n> < > \n> < > Yes.\n> < \n> < No, it is not. You quote POSIX, but the matter of the fact is that we\n> < use a subset of POSIX in order to be able to keep things running on\n> < Windows.\n> \n> As far as I can tell (and as the attached program may help demonstrate),\n> the above assumption has been valid on all versions of Windows since at\n> least Windows 2000.\n\nAnd since W2K is already past its end of life, it would be safe for\npractical considerations.\n\nHowever, I have to add two comments to that:\n\n- it is *not* guaranteed. The behavior is undefined, even if you see\n consistent behavior so far. Future Windows versions might break that\n assumption freely, though.\n\n- some implementations of the REG_STARTEND feature have the nice property\n that they can read past NUL characters. Granted, not all of them do\n (AFAIU one example is FreeBSD itself, the first platform to sport\n REG_STARTEND), but we at least reap the benefit whenever using a regex\n that *can* read past NUL characters.\n\n> In this context, one thing to remember is that the page-size for the mod\n> operation is 4096, whereas the POSIX page-size (for the purpose of mmap\n> and mremap) is 65536.\n\nIndeed. A colleague of mine spotted the segfault when diffing a file that\nwas *exactly* 4,096 bytes.\n\n> Note also that in the case of file-backed mapped sections, using\n> kernel32.dll or msvcrt.dll or cygwin/newlib or midipix/musl is of little\n> significance, specifically since all invoke ZwCreateSection and\n> ZwMapViewOfSection under the hood.\n\nRight. It's all backed by the very same kernel functions.\n\nCiao,\nJohannes\n"}]}