On Sep 3, 2005, at 11:19:17, H. Peter Anvin wrote:
Thus, an ABIzed <linux/abi/stat.h> or whatever it's called might
export
"struct __kabi_stat" and "struct __kabi_stat64" with the
expectation that
the caller would "#define __kabi_stat64 stat" if that is the
version they
want. A typedef isn't good enough for C, since you can't typedef
struct
tags.
Didn't you mean "#define stat __kabi_stat64"? Also, I can see that
would
pose other issues as well say my app does "struct stat stat;" Any error
messages would refer to a variable "__kabi_stat64" instead of the
expected
"stat":
A userspace program:
struct stat stat;
stat.invalid = 1;
Preprocesses into:
struct __kabi_stat64 __kabi_stat64;
__kabi_stat64.invalid = 1;
And gives an error something like this for that line, confusing the
programmer:
Invalid member "invalid" for "__kabi_stat64"
As far as I can tell, this is not a solvable issue unless GCC can
come up
with a way to either:
typedef struct foo struct bar;
or
struct bar { unnamed struct foo; };
the former being much nicer. On the other hand, I think the following
should work, because the st_* names are within the C namespace and
should
be much easier to redefine, although misuse of one of those names might
be a bit more catastrophic for the user app.
struct stat {
struct __kabi_stat64 __stat64;
};
#define st_dev __stat64.st_dev
#define st_ino __stat64.st_ino
[...]
Then the userspace program could do this:
struct stat foo;
foo.st_ino = 0;
And it would be preprocessed into:
struct stat foo;foo.__stat64.st_ino = 0;
Cheers,
Kyle Moffett
--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best
answer:
"Why do musicians compose symphonies and poets write poems? They do
it because
life wouldn't have any meaning for them if they didn't. That's why I
draw
cartoons. It's my life."
-- Charles Shultz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/