{"thread":{"id":"44226","subject":"RE: [musl] Re: Regression: git no longer works with musl libc's regex impl","startedAt":"2016-10-05T16:37:17Z","lastAt":"2016-10-05T16:37:17Z","messageCount":1,"participants":["writeonce@midipix.org"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"303387","messageId":"20161005093711.dc30d64f61e5ec441c34ffd4f788e58e.4f463e82c1.wbe@email15.godaddy.com","threadId":"44226","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-05T16:37:11Z","receivedAt":"2016-10-05T16:37:17Z","isPatch":false,"sender":{"key":"writeonce@midipix.org","avatar":null},"body":"Hi Johannes,\n\n> \n> \n> -------- Original Message --------\n> Subject: RE: [musl] Re: Regression: git no longer works with musl libc's\n> regex impl\n> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n> Date: Wed, October 05, 2016 3:49 am\n> To: writeonce@midipix.org\n> Cc: musl@lists.openwall.com, git@vger.kernel.org, Jeff King\n> <peff@peff.net>\n> \n> Hi writeonce,\n> \n> On Tue, 4 Oct 2016, writeonce@midipix.org wrote:\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\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> \n> And since W2K is already past its end of life, it would be safe for\n> practical considerations.\n> \n> However, 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\nThat is of course the official language, and generally speaking a good\nrule of thumb. However... there is enough information to suggest that\nwhen it comes to mapping of file-backed sections, the NT kernel\ndevelopers will choose to keep things the way they are. In brief, here's\nwhy:\n\nGiven a \"gray zone\" that spans from EOF to end-of-page, there are in\nessence three possible behaviors:\n\n[1] bytes in the gray zone are accessible and are all zero's. This is\nthe current behavior.\n[2] bytes in the gray zone are not accessible; trying to read past EOF\nwould result in a segfault.\n[3] bytes in the gray zone are accessible but might contain random data\nor junk.\n\nAssessment:\n\n[1] backward-compatible, POSIX-compliant, single code path for both\nWIN32 and LXW.\n[2] requires changing memory access granularity from 4096 bytes to a\nsingle byte, and is therefore extremely costly.\n[3] introduces a whole new class of security vulnerabilities, and will\nthus be a lot of fun to watch:-)\n\nAll in all taken, then, I'd argue that relying on the current behavior\nis very reasonable. If you, too, find the above assessment valid, and\nsince you mentioned that you were a Microsoft employee, it would be\ngreat if you could make a good-faith effort to have the current behavior\nadded to the Driver Documentation and thus guaranteed.\n\nPS. this isn't to say that the regex extension should or should not be\nused, only that a decision on the matter should not be based on the\nundocumentedness of current behavior.\n\nmidipix\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> \n> Indeed. A colleague of mine spotted the segfault when diffing a file that\n> was *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> \n> Right. It's all backed by the very same kernel functions.\n> \n> Ciao,\n> Johannes\n\n"}]}