Re: [RFC] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/