> > > i |= (int) (a.st_dev != b.st_dev);
> >
> > Ok, right here. How does this work on any other compiler than
> > gcc? gcc sees a.st_dev and b.st_dev as long long's. Every
> > other compiler sees them as structs and this statement is
> > illegal.
>
> Well, the resolution never uses /linux/asm/stat.h where
> it is declared as an unsigned short, note that there is a pad
> after this to allow it to be another 2 bytes in length. The
> 'C' runtime library has conversion code to promote linux's
> idea of 'struct stat' to a POSIX (I guess) idea of what it should
> be (more reason why not to use kernel headers, only 'C' headers.
I don't follow you here. <asm/stat.h> has nothing to do with
anythng. The code I have include <sys/stat.h> and that's it.
Everything else that gets included is due to #include's in
the header files. I am not including kernel header files
directly.
> The result is.... sizeof(st_dev) is 8 bytes (long - long).
> Now, when the GNU 'C' compiler looks at <gnu/types.h>, it has
> already set variable __GNUC__ so, if you have another compiler
> and you want it to follow the same rules (these are after all GNU
> headers), you have to do -D__GNUC__ and you will get the same
> rules.
The is not feasible since __GNUC__ brings in all sorts of no-standard
gcc-isms that other compilers can't deal with. The long long should
really be guarded with HAVE_LONG_LONG or something, not __GNUC__.
> This will allow __quad_t (was st_dev) to be resolved as
> a long-long. If your compiler doesn't know long-long, you can't
> use the GNU header. In that case, you put -D_GNU_TYPES_ on the
> command line so this header will be skipped. You then have to
> make your own user mode struct stat or (non portably, use the
> kernel's).
I don't like either solution. Ideally, I should be able to use the
OS-provided headers and everything should just work. That's why
they're there, after all. Maybe I have to add some extra compile
flags, but -D__GNUC__ brings in too much baggage.
> Note that you can't just decide to use another compiler without
> using that compiler's headers. Compilers, themselves, are never
> promised to be portable. Instead, they are supposed to allow a
> user to write portable code (if you don't try to out-think them).
Do any compilers provide headers that go into /usr/include/sys,
though? I guess the real problem is in /usr/include/statbuf.h,
however, since it includes /usr/include/gnu/types.h.
Your point is very valid, though. I just don't know of any compilers
that have a replacement for /usr/include/statebuf.h.
-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/