ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Also, pointers won't remain valid and any dynamic memory associated won't carry over. The only reliable way is to decompose the structure into its components and write to the file in some parseable format. For example, separate data by spaces or some other symbol using fprintf, then parse with fgets, strtok, and the strto* functions. The real problem comes if you have non-string pointers. Then you are talking about an entire file format and parser.
ta0kira

1. Endianness- When numbers are stored in memory, they are stored in either big endian or little endian. PowerPC processors (and others) use big endian, while Intel processors (and others) use little endian. (actually, PowerPC can be either big endian or little endian, but it's big endian by default). Suppose you want to store the number 0x12345678. If you do this:

char c[4];
unsigned long n=0x12345678;
*(unsigned long*)c = n;

In big endian, it will be this:

c[0]=0x12;
c[1]=0x34;
c[2]=0x56;
c[3]=0x78;

In little endian, like this:

c[0]=0x78;
c[1]=0x56;
c[2]=0x34;
c[3]=0x12;

Register shifts won't be affected (i.e. 0x12345678<<8 will still be 0x34567800). When working with numbers mathematically, it's the same on big endian or little endian platforms, but when you break numbers down into smaller units (like bytes) it certainly matters. Therefore, writing structs (or numbers larger than char) to a file on a big endian system will result in different byte ordering than doing so on a little endian system.

2. Even alignment- I don't think this is present in mainstream processors (i.e. PowerPC and Intel), but it is in the Motorola 68k processors. The 68k can't write shorts or longs at odd addresses without writing them one byte at a time, so when you say:

Overall, if you're worried about cross-architecture compatibility, heed these notes. Otherwise, at least know this issue exists so that when you do need to write a cross-architecture program, you'll know how.

It is also true that it will most likely not be able to be read by other programs using read.

Fear not. As long as the structure doesn't include pointers and is being run always on the same architecture with (basically) the same compiler, you're fine.

Quote:

it may be eazier and possibly safer to use fread and fwrite rather then the low level file operators.

Be not uncertain. Doubt not. There is nothing to be gained with respect to writing and reading structures through fread() and fwrite() instead of read() and write().

The most likely complication is that you can't always know that a later program (perhaps the same one) might be compiled with a different compiler. As JoeyAdams says, this might mess up alignment of items in a struct, giving you problems.

All you gain from this is saving disk space (how much would you really be saving, anyway?) and speed. Unless writing and reading these records consumes a large percentage of your processing time, go with ta0kira's idea of writing the data in human-readable form. It will be easier to maintain the code if your eyes can see the data.

Be not uncertain. Doubt not. There is nothing to be gained with respect to writing and reading structures through fread() and fwrite() instead of read() and write().

fwrite and fread are, also, generally faster, since they buffer buffer the input/output. You can do the same with read and write, but you usually end up reimplementing fread/fwrite, only not as robust or safe.

Edit: It is also ANSI C.

-
OP:
For now, stick to the basics. Try using both ta0kira's method, and just straight binary reading/writing as well. You're learning, so it is all good for you and you'll learn a lot both ways. When you start getting a little more advanced then you can start dealing with more advanced serialization.