Bug Report: Regression in Cygwin 2.11.0-1

David Allsopp David.Allsopp@cl.cam.ac.uk
Sat Sep 1 16:42:00 GMT 2018

Corinna Vinschen wrote:
> On Sep  1 09:56, Andreas Hauptmann wrote:
> > On Sat, 1 Sep 2018 01:24:49 +0000
> > Bryan Phelps wrote:
> >
> > > I'll continue to look around for a more minimal repro,
> >
> > The normalization of paths with backslashes has changed.
> >
> > The following doesn't work any longer:
> >
> >     cd /tmp
> >     stat "..\bin\file.exe" # or
> >     stat "..\\bin\\file.exe"
> >
> > This however still works:
> >
> >     stat "C:\cygwin\bin\file.exe"
> I know where the problem is.  A new piece of code fixing a crash due to a buffer
> underflow is too aggressively guarding the path buffer against this underflow
> when normalizing ".." in Win32 paths.
> I'll fix this and release a 2.11.1 soon, but I still have a question:
> Why do I push out test releases if nobody cares?

Like you, we're a (very) small number of maintainers - and, as far as I'm aware, the command line setup doesn't exactly make continuous integration testing of Cygwin test versions "trivial". I'd love to have had the time within the last 22 days to service my care...

> In terms of this OCAML build system problem:
> Please fix your build system.  Do not mix POSIX and Win32 paths, use POSIX
> paths only.  Backslashes are *no* drop-in replacement for slashes.

The "problem" for us is more subtle than this. The program which is generating that path is not a Cygwin executable, so it is correctly combining a path it has been supplied (the ../stdlib which has been supplied via Cygwin's make) with a filename, so it uses a backslash. It's been on my TODO for years to enhance to understand that the program it's supplying the path back to is a Cygwin executable and so sort it out properly but, well, we're a small number of maintainers! That said, WSL is forcing us to address it properly... 

> Some of the path handling is seriously crippled as soon as you start using
> backslashes, and that's a delipberate decision and won't change, even after
> fixing the aforementioned bug.

I don't quite follow this - does that mean that that path definitely work even with a new Cygwin? i.e. our existing build system is permanently broken for Cygwin 2.11+?


Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

More information about the Cygwin mailing list