Is it possible to write a struct to binary file?

[bergko]

Hi there,
I'm thinking of how to write a struct to a binary file, could anyone
help me with this?

for example

typedef struct record{

char *name
int contact
}rec;

file1 = fopen(..,"wb");
...
fwrite(rec, sizeof(rec),1,file1);

I've tried the above but it doesn't seem to work properly. Could anyone
help me.
thanks

 

[Vladimir S. Oka]

bergko opined:

Hi there,
I'm thinking of how to write a struct to a binary file, could anyone
help me with this?

for example

typedef struct record{

char *name
int contact
}rec;

file1 = fopen(..,"wb");
..
fwrite(rec, sizeof(rec),1,file1);

I've tried the above but it doesn't seem to work properly. Could

Of course it doesn't -- for various reasons. Most important one being
that your `rec` is type not a variable. If you used `sizeof` as a
function to shut up your compiler, you shouldn't have.

Below is some code that demonstrates what you may want, but beware, it
has no error checking whatsoever, and makes some assumptions that may
not hold for you (e.g. that "testfile" is a valid file name). It does
compile cleanly, and runs as expected on my Linux box.

/* CAVEAT EMPTOR */

#include <stdio.h>

typedef struct record{
char *name;
int contact;
} rec ;


int main(void)
{

FILE *file1;
rec a_rec = {NULL, 42};
rec b_rec = {NULL, 24};

printf("%d\n",a_rec.contact);
printf("%d\n",b_rec.contact);

file1 = fopen("testfile","wb");
fwrite(&a_rec, sizeof a_rec, 1, file1);
fclose(file1);

fopen("testfile","rb");
fread(&b_rec, sizeof b_rec, 1, file1);
fclose(file1);

printf("%d\n",a_rec.contact);
printf("%d\n",b_rec.contact);

return 0;
}

 

[CBFalconer]

I'm thinking of how to write a struct to a binary file, could
anyone help me with this?

for example

typedef struct record{
char *name
int contact
}rec;

file1 = fopen(..,"wb");
..
fwrite(rec, sizeof(rec),1,file1);

I've tried the above but it doesn't seem to work properly. Could
anyone help me.

It is working fine. However what it writes is meaningless when
read back, since the pointer to name almost certainly will be
invalid.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard Bos]

bergko opined:

Of course it doesn't -- for various reasons. Most important one being
that your `rec` is type not a variable. If you used `sizeof` as a
function to shut up your compiler, you shouldn't have.

More to the point, _it_ shouldn't have.

Below is some code that demonstrates what you may want, but beware, it
has no error checking whatsoever, and makes some assumptions that may
not hold for you (e.g. that "testfile" is a valid file name). It does
compile cleanly, and runs as expected on my Linux box.

typedef struct record{
char *name;
int contact;
} rec ;

rec a_rec = {NULL, 42};
rec b_rec = {NULL, 24};

fwrite(&a_rec, sizeof a_rec, 1, file1);

fread(&b_rec, sizeof b_rec, 1, file1);

Another, more important, catch is that this you can only expect to read
back a valid pointer value if it was null to begin with, or if you are
still running the same execution of the program and haven't deallocated
the memory that the pointer pointed at.
For example, writing a pointer to an automatically allocated array and
then reading it back in another call of the same function may easily put
that array in another place in memory, making the pointer invalid.
Writing a pointer in one run of the program, and reading it back in
another, is even more likely to do the same.

Richard

 

[Vladimir S. Oka]

More to the point, _it_ shouldn't have.

Yes, for the first mention of `rec`. Seeing OP had typed the code
without care to make it barely correct, I disregarded that bit.

Another, more important, catch is that this you can only expect to read
back a valid pointer value if it was null to begin with, or if you are
still running the same execution of the program and haven't deallocated
the memory that the pointer pointed at.
For example, writing a pointer to an automatically allocated array and
then reading it back in another call of the same function may easily put
that array in another place in memory, making the pointer invalid.
Writing a pointer in one run of the program, and reading it back in
another, is even more likely to do the same.

You are, of course, right. I managed to overlook (as in "saw but did
not see") the fact that one member is actually a pointer. It also
wasn't clear (to me) what exactly was OP's problem: getting it to
compile and run, or perform as expected (whatever it was that was
expected).