Re: [PATCH v3 3/8] mingw: make failures to unlink or move raise a question

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Dec 15, 2010, 09:09 UTC
Message-ID: <AANLkTi=vkkHmzmmGshn6v5E0e5mVkt0PMCkdhk=Mvn4u@mail.gmail.com>
In-Reply-To: <7v1v5jrb1f.fsf@alter.siamese.dyndns.org>

On Wed, Dec 15, 2010 at 4:05 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > @@ -129,6 +130,78 @@ static inline int is_file_in_use_error(DWORD errcode)
>>> >        return 0;
>>> >  }
>>> >
>>> > +static int read_yes_no_answer()
>>>
>>> Perhaps "static int read_yes_no_answer(void)" for portability?
>>
>> LOL. This file is called compat/mingw.c... :-)
>
> I had the same reaction.  Maybe MinGW will get a different compiler
> someday ;-)
>

We already have; compat/msvc.c includes compat/mingw.c. mingw.c is called mingw.c because it was the first native windows port, not because it will always be compiled with MinGW. So this file is REALLY more about the OS than the compiler.

I don't think MSVC has a problem with this declaration either, but wouldn't it be nicer if we had Windows-code that was as portable as possible across compilers? I've also been playing around with the idea of using LLVM's clang for Git on Windows, because it's support for cross compiling between 32bit and 64bit is a bit less nasty than MinGW's. This might never come happen, and I don't know if clang supports this or not. And then there's Intel's ICC that some times outperforms GCC. I don't think it would hurt fixing it in case people will port - one less trip-wire in the code.

But I of course only suggest this because this is new code. It's easy to change it to be slightly more portable (and more consistent with the rest of the code base), so why not?