Re: [Mingw-users] S_IRWXG, S_IRWXO undefined when building gcc 4.9.2 with mingwrt 3.20

[Keith M. <kei...@us...>]

Hi David,

On 10/03/15 04:35, Keith Marshall wrote:
> On 05/03/15 21:42, David Gressett wrote:
>> The offending line of code is protected inside an #ifdef HAVE_UMASK.
> 
> I suspect that this may be a red herring.

It is; the issue is not related to HAVE_UMASK.

>> This leads me to believe that something in mingwrt 3.21 is causing the
>> gcc 4.9.2 build to be misconfigured and it is causing HAVE_UMASK to
>> be defined  when it should not be, ...
> 
> I'm not convinced; see above.

I am convinced, now: your belief that something in mingwrt-3.21 has
raised an issue is correct, but you've jumped to the wrong conclusion
regarding its relationship to HAVE_UMASK.

>> Does anybody have any idea  what could be causing this? The next 
>> step is to compare the present and previous versions of mingwrt,
>> but I don't want to waste time reinventing wheels that someone else
>> already knows about.
> 
> The only change that I can think of, which might have a bearing, is that
> _mingw.h now defines _POSIX_C_SOURCE as 200809L,

This is also an incorrect presumption ...

> Beyond this, I have no suggestions to offer; you'll need to investigate
> the issue for yourself, as I simply don't have time to look into it ATM.

I did find time to take a quick peek into libgfortran/io/unix.c; the
issue arises because of the #ifdef HAVE_MKSTEMP, which encloses the
#ifdef HAVE_UMASK you've questioned. See, mingwrt-3.21 now provides an
implementation of mkstemp(3), where previous versions did not, causing
HAVE_MKSTEMP to become defined, and exposing the (presumably) long
standing bug in libgfortran/io/unix.c ... it gratuitously, (and quite
erroneously), assumes that any runtime implementation which provides
mkstemp(3) must also define S_IRWXG and S_IRWXO, neither of which has
any meaning on Windows.

The correct resolution for this is to remove the bogus assumption from
libgfortran/io/unix.c; a simple workaround is to append

  && !defined(__MINGW32__)

to each of the three preprocessor conditionals, within tempfile_open(),
which test HAVE_UMASK, (for it is within their scope that the bogus
assumption appears).  However, the libgfortran maintainers may wish to
consider some other corrective mechanism.

-- 
Regards,
Keith.