On Tue, Sep 28, 2010 at 11:20 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Tue, Sep 28, 2010 at 11:13 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: >> On Dienstag, 28. September 2010, Erik Faye-Lund wrote: >>> On Tue, Sep 28, 2010 at 10:52 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: >>> >> mingw: do not crash on open(NULL, ...) >>> > >>> > This one is bogus, and as it stands, it must have my Ack removed. :) >>> > Needs the same fix in mingw_fopen as mingw_freopen. (There remains an >>> > unprotected dereference of filename.) >>> >>> I believe the version in for-junio already has this fix squashed in. >>> The following hunk, taken from >>> http://repo.or.cz/w/git/mingw/4msysgit.git/blobdiff/4e93566b07dcf47ecb6484d >>>225418c04c1eedee6..b18500977d88b13803ecc60cf383538139ec09d8:/compat/mingw.c >>> shows that it is... Or are you thinking of something else? >>> >>> @@ -346,7 +346,7 @@ FILE *mingw_fopen (const char *filename, const char >>> if (hide_dotfiles == HIDE_DOTFILES_TRUE && >>> basename((char*)filename)[0] == '.') >> ^^^^^^^^ >> This can crash, too. >> > > Ah, indeed. Thanks for pointing that out! I'll send out a new version, > with this squashed on top: > And now that I assemble it, I all of a sudden understand where your complaint came from. The issue wasn't in the original patch, it was introduced when the patch was applied. Basically, I introduced a similar crash-bug to the one this patch fixes in the original hide-dotfiles patch, and my this patch was written against junio's master, which doesn't contain that newer bug. I also seem to remember there being some controversy over the hide-dotfiles series, whether or not it was in git's scope to allow hiding non-dotgit files at all etc. So, perhaps what makes the most sense would be to eject the hide-dotfiles stuff out of for-junio, and rework it on top, going through the main git mailing list? That series did get quite a bit messy as patches were applied a little too quickly IMO. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html