This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
- From: "pinskia at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 20 Jul 2015 09:19:10 +0000
- Subject: [Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
- Auto-submitted: auto-generated
- References: <bug-66936-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Keith Marshall from comment #8)
> (In reply to kargl from comment #7)
> > So add
> >
> > #define S_IRWXG 0
> > #define S_IRWXO 0
> >
> > to the header file wherever mingw defines the available mask bits
> > for umask(3). The bug is clearly in mingw were it gratuitously maps
> > umask() to _umask() without properly adding the mappings for the
> > mode_t argument bits of umask(3).
>
> Absolutely not! Those bits are utterly irrelevant for the windows (MinGW)
> platform; to add them would be do nothing more than create confusion. The
> mask bits for umask(), on the windows platform are S_IREAD | S_IWRITE; those
> are the only mask bits YOUR code should be passing to non-POSIX
> umask(5axxx3be.aspx).
>
> This is NOT a MinGW bug; it's a GCC bug, and that's where it should be
> fixed. Until you do fix it, I have my work-around, (which I'm perfectly
> willing to publish in MinGW forked source for GCC, prominently commented as
> a ghastly hack to circumvent a gross upstream GCC bug).
Well it is a libgfortran bug yes. What we could do add to io/unix.c:
#if MINGW && !defined(S_IRWXG)
#define S_IRWXG 0
#endif
#if MINGW && !defined(S_IRWXO)
#define S_IRWXO 0
#endif
And that will allow it to work correctly.