current address

[Vu Pham]

In order to mark the current address at a given point of the variable block,
I use the char dummy[0] as follows :

int a;
long b;
short int c;
char dummy[0];

By this way, I can calculate the size of the memory block that contains all
the vars : size = dummy - ( char *) & a;

Is there any other way to do this ? Such as

_bookmark1
int a;
long b;
short int c;
_bookmark2

size = bookmark2 - bookmark1;

Thanks,

Vu

 

[Sam Dennis]

int a;
...
char dummy[0];

This is a constraint violation and your compiler should warn you of it.

By this way, I can calculate the size of the memory block that contains all
the vars : size = dummy - ( char *) & a;

It might work for you, but the standard doesn't guarantee anything about
the result of this statement or anything thereafter.

Is there any other way to do this ?

Not portably, although you could get some sort of result by placing your
declaration in a struct as fields (and taking the size of the struct); I
would suggest that you are probably mistaken in believing that you would
ever need such functionality, though.

 

[Vu Pham]

int a;
...
char dummy[0];

This is a constraint violation and your compiler should warn you of it.

Yes, on one compiler, I get a warning, on another one, I get an error :-(

It might work for you, but the standard doesn't guarantee anything about
the result of this statement or anything thereafter.


Not portably, although you could get some sort of result by placing your
declaration in a struct as fields (and taking the size of the struct); I
would suggest that you are probably mistaken in believing that you would
ever need such functionality, though.

What I am doing is to save the current status of my app to disk. Instead of
saving each of these variables, I would like to save them as a continuos
block. I understand that memory alignment can make this block to have
different size but , for my app, this saved data will not be moved to other
platforms without being recreated correspnodingly.

In such case, is there any keyword/method ... could help me to get the
current address as described ? I can declare another variable like char
dummy ( instead of char dummy[0] ) but this will add an extra variable that
my app really does not need.

Thanks,

Vu

 

[Malcolm]

What I am doing is to save the current status of my app to disk.
Instead of saving each of these variables, I would like to save them
as a continuos block. I understand that memory alignment can
make this block to have different size but , for my app, this saved
data will not be moved to other platforms without being recreated
correspnodingly.

C isn't the right language for this. Normally your compiler will come with
documentation about how to interface to assembly programs, and from assembly
you can find the stack quite easily (probably) and save it, also
reconstitute it on reload.

 

[Jens.Toerring]

int a;
...
char dummy[0];

This is a constraint violation and your compiler should warn you of it.

Yes, on one compiler, I get a warning, on another one, I get an error :-(

What I am doing is to save the current status of my app to disk. Instead of
saving each of these variables, I would like to save them as a continuos
block. I understand that memory alignment can make this block to have
different size but , for my app, this saved data will not be moved to other
platforms without being recreated correspnodingly.

There's no guarantee that the first variable has the lowest memory
address. There is no guarantee that the compiler places the varia-
bles into a continuous memory region. And there isn't even a guaran-
tee that all variables really exist in memory - some could just
exist in registers of the CPU, and even if they exist in memory
you can't be sure that the values in memory are the real values of
the variables - the CPU could work on a copy in a register.

What about putting them all in structure an then write out that
structure explicitely as Sam told you to do? In this case you can
be sure that all members really exist in memory, you know exactly
how many bytes you have to write out without resorting to strange
tricks and the program will know that you need the real values of
all members (so things copied to CPU registers must be updated to
memory) when you write the structure to a file.

Regards, Jens

 

[Martin Ambuhl]

In order to mark the current address at a given point of the variable block,
I use the char dummy[0] as follows :

int a;
long b;
short int c;
char dummy[0];

By this way, I can calculate the size of the memory block that contains all
the vars : size = dummy - ( char *) & a;

No, you can't. There are no guarantees about where these various
variables are stored: none about the order, none about propinquinty.

Is there any other way to do this ?

The _only_ way, I believe, is to stick all those variables in a struct.
Your way sure as hell won't work.

 

[Mac]

In order to mark the current address at a given point of the variable block,
I use the char dummy[0] as follows :

int a;
long b;
short int c;
char dummy[0];

By this way, I can calculate the size of the memory block that contains all
the vars : size = dummy - ( char *) & a;

Is there any other way to do this ? Such as

_bookmark1
int a;
long b;
short int c;
_bookmark2

size = bookmark2 - bookmark1;

Thanks,

Vu

There's no way to do what you want to do that is portable or on-topic in
this newsgroup.

One thing you could do is define a variable (e.g., "size") as a place
holder, and assign it any old constant value (e.g., 42).

Then compile the code to assembly language, and inspect it to see what
"size" should be. Then change the code so "size" is initialized to the
right value and re-compile. I am not recommending that you do this. I'm
just throwing it out there as an idea. Certainly if anyone will ever have
to maintain this code down the road, you need to find a cleaner solution.

Since this is off-topic, please don't reply here.

good luck!

--Mac

 

[Thomas Matthews]

In order to mark the current address at a given point of the variable
block,
I use the char dummy[0] as follows :

int a;
long b;
short int c;
char dummy[0];

By this way, I can calculate the size of the memory block that
contains all
the vars : size = dummy - ( char *) & a;

No, you can't. There are no guarantees about where these various
variables are stored: none about the order, none about propinquinty.

Is there any other way to do this ?

The _only_ way, I believe, is to stick all those variables in a struct.
Your way sure as hell won't work.

There is always the brute force method of writing each variable
independently to the file.

When variables are in a struct and written to a file, they are not
portably read in; they must be read in individually, one by one.

The OP should also remember that although pointer can be written
to a file, there is no guarantee that the object they pointed to
will be at the same location. Thus pointers should not be written
to a file.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Martin Ambuhl]

Thomas Matthews wrote:

When variables are in a struct and written to a file, they are not
portably read in; they must be read in individually, one by one.

As soon as you start writing variables directly to a file, rather than
textual representations of them, you give up all hope of portability.
This is not unique to writing structs to a file.

 

[Keith Thompson]

There is always the brute force method of writing each variable
independently to the file.

When variables are in a struct and written to a file, they are not
portably read in; they must be read in individually, one by one.

It should be reasonably safe if the structs are read in by the same
program, compiled with the same compiler on the same system.

The OP should also remember that although pointer can be written
to a file, there is no guarantee that the object they pointed to
will be at the same location. Thus pointers should not be written
to a file.

If the pointers are written and then read back in during the same
execution of the same program, you're probably ok as long as the
pointed-to objects haven't reached the end of their lifetimes. (This
is a much more stringent condition than the one above for structs in
general). On the other hand, if the program is still running, it
almost certainly makes more sense just keep the pointers in memory;
there's little to be gained by writing them to files and reading them
back in (unless you're trying to simulate vitual memory on a system
that doesn't support it).

I think what the OP is trying to do is what's called checkpointing.
It's a feature supported on some high-performance batch-processing
systems (supercomputers), where a computational job can easily run for
weeks, and the system is likely to go down before the job finishes.
There's no way to do this in portable C (so it's off-topic here), but
some research into whether your system supports checkpointing might be
fruitful.

 

[Gordon Burditt]

When variables are in a struct and written to a file, they are not

It should be reasonably safe if the structs are read in by the same
program, compiled with the same compiler on the same system.

You may need the restriction "same VERSION of the same program".
....

I think what the OP is trying to do is what's called checkpointing.
It's a feature supported on some high-performance batch-processing
systems (supercomputers), where a computational job can easily run for
weeks, and the system is likely to go down before the job finishes.
There's no way to do this in portable C (so it's off-topic here), but
some research into whether your system supports checkpointing might be
fruitful.

I am reminded here of the save technique used in some old text and
curses-based games such as Zork and Rogue. The "save game" code
wrote a new executable (no way this is portable) using the original
code from the original executable, and it constructed a data segment
as the entire range of memory from the symbol _etext to sbrk(0)
(and this is a thousand times WORSE), encrypted. Needless to say,
this was EXTREMELY unportable (and, I suspect, actually worked on
0 machines, but sort of worked on at least Vaxes and PDP-11s). The
code made assumptions about the relative positions of the text
segment, data segment and the malloc() arena.

I recall trying to get this working on a machine where the end of
the code segment came *AFTER* the end of the malloc arena (Tandy
6000 / 68000-based). Also, it had a fixed-size stack, which came
between the data segment and the malloc arena. Nothing like trying
to encrypt the stack while using it. The result was not pretty.
But I eventually got it to work almost as well as the original did.

One of the larger problems with this code is that a save/restore
cycle saved and restored variables from library code that it knew
nothing about. Saving a game using one curses terminal type and
restarting it on another was problematical. A few library "initialize
once only" flags got restored as initialization having been done,
but the effect of the initialization (e.g. opening a file) was
reversed by the save/restore cycle, or, in the case of the curses
code, kept the old terminal type instead of using the new one.
Attempting to free() memory that was malloc()ed before a save/restore
cycle but which had been turned into static data also caused trouble
sometimes, but mostly, it just leaked memory.

Every save/restore cycle grew the process by including what was
formerly malloc()ed memory in the new data segment. After maybe
15 or 20 save/restore cycles, it got too big and tended to crash,
just when you got a good game going and were getting a high score.

Someone tried converting this to X. Something in the X libraries
objected violently to the brute-force save/restore method, and
a saved game aborted immediately when restarted.

I believe some of the newer (but still pretty old) games of similar
type, such as "nethack", actually make a point of saving only
variables that they know about. I don't think it can deal with
the situation of reloading a game into a new version where the
saved structures have changed size, or type, or values of some
of the "enum-like" variables got rearranged.

Gordon L. Burditt

 

[Vu Pham]

Thomas Matthews wrote:



As soon as you start writing variables directly to a file, rather than
textual representations of them, you give up all hope of portability.
This is not unique to writing structs to a file.

Yes, as I mentioned in my previous post, the written file will not be moved
around different platform.

Vu

 

[Dan Pop]

int a;
...
char dummy[0];

This is a constraint violation and your compiler should warn you of it.

Yes, on one compiler, I get a warning, on another one, I get an error :-(

It might work for you, but the standard doesn't guarantee anything about
the result of this statement or anything thereafter.


Not portably, although you could get some sort of result by placing your
declaration in a struct as fields (and taking the size of the struct); I
would suggest that you are probably mistaken in believing that you would
ever need such functionality, though.

What I am doing is to save the current status of my app to disk. Instead of
saving each of these variables, I would like to save them as a continuos
block. I understand that memory alignment can make this block to have
different size but , for my app, this saved data will not be moved to other
platforms without being recreated correspnodingly.

In such case, is there any keyword/method ... could help me to get the
current address as described ? I can declare another variable like char
dummy ( instead of char dummy[0] ) but this will add an extra variable that
my app really does not need.

Yes, you can do that easily, using the address of the last variable you
have defined in that particular sequence of definitions:

int a;
...
float x;

Let's assume that x is the last variable and you want to compute the
number of bytes that need saving:

size_t size = (char *)&x - (char *)&a + sizeof x;

The things you have to keep in mind are:

1. The result of this expression is not guaranteed by the language, its
evaluation actually invokes undefined behaviour. On most modern
implementations it works as intended, though. Beware of those that
attempt to do bound checking on pointer arithmetic, however.

2. The order of allocation is not necessarily the same as the order of
definition: you *must* check, e.g. by looking at the assembly output
of the compiler or at the symbol map of the linker (if dealing with
external definitions) that a is indeed the first variable allocated
and x is the last.

As other people told you, the solution that is guaranteed to work for
your problem is encapsulating all the data that needs to be saved and
restored in a structure. If, for one reason or another this is not
acceptable to your application, you can (try to) do the things your
way as shown above, but you must *really* check that the compiler
behaves according to your assumptions.

Dan

 

[Dan Pop]

C isn't the right language for this.

Most of the time it is.

Normally your compiler will come with
documentation about how to interface to assembly programs, and from assembly
you can find the stack quite easily (probably) and save it, also
reconstitute it on reload.

And what are the advantages of an assembly-based solution? His own
approach is far more portable, if he checks that the implementations
of interest behave according to his assumptions.

Dan

 

[Michael Wojcik]

I am reminded here of the save technique used in some old text and
curses-based games such as Zork and Rogue. The "save game" code
wrote a new executable (no way this is portable) using the original
code from the original executable, and it constructed a data segment
as the entire range of memory from the symbol _etext to sbrk(0)
(and this is a thousand times WORSE), encrypted. Needless to say,
this was EXTREMELY unportable (and, I suspect, actually worked on
0 machines, but sort of worked on at least Vaxes and PDP-11s). The
code made assumptions about the relative positions of the text
segment, data segment and the malloc() arena.

The "freeze" feature (I use the term loosely) of emacs circa 1991 was
implemented similarly. I'm not an emacs user myself - vim has more
features than I could ever want - but I had a friend who was using it
on the brand-new AIX 3 and found that "freeze" produced a nonworking
executable. emacs implemented freeze by forcing a core dump, and
then editing the core dump to turn it into an executable.

It was a nifty hack, but just as unportable as it sounds. I poked at
it a couple of times just to see what it did, then told him to forget
freezing and just reload all his customizations each time he started
emacs. That took only a couple of seconds, and he didn't start emacs
very long - usually just cranked it up and left it running all day.

Still, it probably wasn't as bad as my own Worst C Hack Ever - a test
framework for BSD (IBM AOS 4.3) on the PC RT which built function
invocations on the fly, creating properly aligned parameters (from
data in the test script) in an array on the stack and then calling
the function to be tested. At the time I thought I was very clever;
now I can't believe the damn thing worked at all.

--
Michael Wojcik (e-mail address removed)

I said, 'I need to put my soul into my work and it is well known that
computers haven't got a soul.' My father said, 'The Americans are working
on it.' -- Sue Townsend, _The Secret Diary of Adrian Mole, Aged 13 3/4_