On Tue, May 15, 2012 at 12:03 PM, Tobias Burnus <bur...@net-b.de> wrote: > Dear all, > > the motivation for the following is rbmj's patch for libstdc++ on VxWorks, > cf. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00073.html > > Note that gfortan is used on VxWorks as the following email proves: > http://gcc.gnu.org/ml/fortran/2012-02/msg00115.html > (VxWorks is a real-time embedded operating system: > https://en.wikipedia.org/wiki/VxWorks) > > > Seemingly, VxWorks differs from POSIX. POSIX [1] has > int open(const char *path, int oflag, ... ); > and requires only with O_CREAT as third argument at mode_t. By contrast, > VxWorks has the following prototype [2] > int open (const char * name, int flags, int mode) > where "mode" is not optional and the function is not variadic. > > > This patch does now always passes a mode on VxWorks; I assume that the mode > is ignored if there is no O_CREAT. That part of the code gets only accessed > if there is no "access" function; looking at [2], that seems to be the case > for VxWorks.
IMHO it would be cleaner if you instead somewhere in the beginning of unix.c did #ifdef __VXWORKS__ /* open is not a variadic function on vxworks (or something...) */ #define open(path, flags) open(path, flags, 0666) #endif Untested, but AFAICS it should work (unless I'm missing something wrt macro expansion, which of course is quite possible). > Additionally, in the fall-back implementation of "mkstemp", "open" with > O_CREAT is used but no mode has been passed. I added 0600 unconditionally. Good catch. This part is ok as is. > The patch was build on x86-64-linux, but I only expect an effect on VxWorks > and on systems without mkstemp. > OK for the trunk? (Is there a need for backporting?) Ok with the above change. I suspect there isn't that much demand for gfortran on vxworks, but the patch isn't intrusive either so if you want to backport it go ahead. -- Janne Blomqvist
