Dear Janne,
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
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).
Testing shows that CPP does not like it:
$ cpp
#define a(x,y) a(x,y,0666)
a(1,2)
a(1,2,3)
# 1 "<stdin>"
# 1 "<command-line>"
# 1 "<stdin>"
a(1,2,0666)
<stdin>:3:8: error: macro "a" passed 3 arguments, but takes just 2
a
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.
There might be not much demand, but it *is* being used on VxWorks, thus,
it potentially affects real users.
However, I was told that VxWorks 6.6 *does* have access() [1] and it is
defined in unistd.h of 6.3. (Recall that fallback_access does not get
complied if HAS_ACCESS is true.) He didn't know whether it is available
in all versions of VxWorks, however. Additionally, he has heard about
gfortran issues (but has no experience with them); and he promised to
compile everything to see whether everything works.
[1]
http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_api_reference_6.6.pdf
In light of the CPP issue and the HAS_ACCESAS: Shall I only commit the
second part or also the VxWorks part?
Tobias
