Re: struct stat
- From: James Kanze <james.kanze@xxxxxxxxx>
- Date: Wed, 29 Oct 2008 02:57:07 -0700 (PDT)
On Oct 27, 9:20 pm, Eric Sosman <Eric.Sos...@xxxxxxx> wrote:
Bjarni Juliusson wrote:
[...]
If GPS is right, there is no way to know the size of the
structure in assembly language, and the only way to do it is
to use C for the system calls.
Also note that I didn't say I would necessarily perform the
system calls directly in assembly; but even if I call the
libc wrappers, I still need to know the size of any
structures in advance.
... and the offsets, sizes, and meanings of its elements, too.
If you really wanted to keep the C parts separate from the
assembly parts (to avoid needing to thumb through the
definitions of the various structs and the typedefs that
contribute to them), you'd probably want to write a C wrapper
that exported the size as a global variable and provided
getters and/or setters for the fields.
You could also write a small C++ program which generates
assembler declarations, using sizeof and offsetof. Something
like:
std::cout << "stat_size = "
<< sizeof( struct stat ) << std::endl ;
std::cout << "stat_dev_offset = "
<< offsetof( struct stat, st_dev ) << std::endl ;
// ...
(Using the GNU assembler syntax.)
Another question: Does this mean that if the kernel is
upgraded, changing the size of struct stat or some other
structure, all C programs on the system need to be relinked
with a new version of libc, or at least a new build of the
same libc?
Different Unix versions have different ideas about the
importance of version-to-version binary compatibility. But
redefining a "public" interface like `struct stat' seems like
a drastic step that no Unix would undertake except in direst
need. Note that such a redefinition would require not only
that all programs link with updated libraries, but that many
programs be recompiled from source.
I was under the impression that binary compatibility of
executables was maintained by the use of dynamicly linked
objects. If a new version breaks binary compatibility of
executables, it changes the magic in the executable file (or
some other information, so that it can detect the version of a
binary, and adjust the .so it dynamically loads accordingly.
Of course, he would have to recompile and regenerate all of his
program if he wanted to recompile anything. But he could still
manage the problem by putting the generation of his assembler in
his makefile, along with some sort of test on the results.
You may well find differing `struct stat' sizes and layouts on
different systems, but it seems highly unlikely that the
`struct stat' on any particular system would ever change.
I doubt that it will change often; it's not like the function is
a new innovation, still somewhat experimental. But in general,
I wouldn't count on a struct at the system API level never
changing.
--
James Kanze (GABI Software) email:james.kanze@xxxxxxxxx
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
.
- Follow-Ups:
- Re: struct stat
- From: Scott Lurndal
- Re: struct stat
- References:
- struct stat
- From: Bjarni Juliusson
- Re: struct stat
- From: Barry Margolin
- Re: struct stat
- From: Bjarni Juliusson
- Re: struct stat
- From: Eric Sosman
- struct stat
- Prev by Date: Re: controlling terminal and virtual terminal
- Next by Date: Re: struct stat
- Previous by thread: Re: struct stat
- Next by thread: Re: struct stat
- Index(es):
Relevant Pages
|