On 05/16/2012 07:26 AM, Janne Blomqvist wrote:
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus<bur...@net-b.de> wrote:
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
Ah, bummer. We have something roughly similiar for snprintf (see
libgfortran.h), but it seems that it works slightly differently due to
using a variadic macro etc. So it seems this idea will not work,
sorry.
Actually, this works for me:
$ cat test.c
#include <stdio.h>
void a(int b, int c, int d) {
printf("%i\t%i\t%i", b, c, d);
}
#define a(b, c) (a)(b, c, 3)
int main() {
a(1, 2);
return 0;
}
$ gcc test.c -o a.out
$ ./a.out
1 2 3
The significance is in the parentheses in the macro definition.
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
Interestingly, according to that document open() also has the POSIXly
correct varargs prototype. So apparently the old 3-argument prototype
was used only in some older vxworks version? Since the document above
is from 2007, one wonders how long ago did the prototype change, and
how much new development is done on these older vxworks versions?
In light of the CPP issue and the HAS_ACCESAS: Shall I only commit the
second part or also the VxWorks part?
IMHO lets do only the second part now, and wait for someone with
vxworks experience to pop in and explain what changes are necessary,
and which vxworks versions are worth considering to support.
I'm using the VxWorks 6.3 headers. The reason for this is that these
headers are available at [1], and that this is the version of VxWorks
used for FRC. I can also say that these headers do NOT contain the
POSIX-ly correct version of open(). Additionally, they do NOT have the
POSIX-ly correct version of ioctl(), so something like the following is
needed:
#define ioctl(a, b, c) (ioctl)(a, b, (int)c)
To explain FRC- I'm a high school student on a FIRST Robotics
Competition team working on getting a full gcc4 toolchain, as the
provided toolchain is gcc 3.4 and windows binaries . Please don't hold
my age/experience (or lack thereof) against me. So if you're looking
for users, there's probably around 100,000 of us high school students in
FRC around the world
[1]: ftp://ftp.ni.com/pub/devzone/tut/updated_vxworks63gccdist.zip
Robert Mason
