faqcat6b6b.html

this is a mirrored site c-faq. thought might need offline

<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is there a way to
compare structures
automatically?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
There is
not a
good
way

for a compiler to implement
structure
comparison
(i.e. to support the <TT>==</TT> operator for structures)
which is consistent with C's low-level flavor.
A
simple

byte-by-byte comparison could
founder on

random bits
present in unused ``holes'' in the structure
(such padding is used
to keep the alignment of later fields correct;
see
question
<a href="faqcat6b6b.html?sec=struct#padding">2.12</a>).
A field-by-field comparison might require unacceptable amounts of
repetitive
code for large structures.
Any


compiler-generated
comparison
could not be expected
to compare pointer
fields
appropriately
in all cases:
for example,
it's often appropriate to compare <TT>char&nbsp;*</TT>

fields
with <TT>strcmp</TT> rather than <TT>==</TT>
(see also question <a href="faqcate107.html?sec=charstring#stringeq">8.2</a>).
</p><p>
If you
need
to compare two structures,
you'll have to
write your own function to do so,
field by field.
</p>




<p>References:

K&amp;R2 Sec. 6.2 p. 129
<br>
Rationale Sec. 3.3.9
<br>
H&amp;S Sec. 5.6.2 p. 133
<hr><hr><hr>
<a name="passret">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/passret.html"><!-- qtag -->Question 2.9</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How
are
structure passing and returning
implemented?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
When structures are passed as arguments to functions,
the entire structure is typically pushed on the stack,
using as many words as are required.

(Programmers often choose to use
pointers to structures instead,
precisely to avoid this overhead.)
Some compilers
merely
pass a pointer
to the structure,
though they may have to make a local copy
to preserve
pass-by-value

semantics.

</p><p>Structures are often returned from functions
in a location pointed to by an extra,
compiler-supplied
``hidden'' argument
to the function.

Some older compilers used a special, static location for structure returns,
although this made structure-valued functions
non-reentrant,
which ANSI C disallows.
</p>

<p>References:

ISO Sec. 5.2.3
<hr><hr><hr>
<a name="anonstruct">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/anonstruct.html"><!-- qtag -->Question 2.10</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can
I pass constant values to functions which accept structure arguments?
How can I create nameless, immediate, constant structure values?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Traditional C had no way of generating anonymous structure values;
you had to use a temporary structure variable



or
a little structure-building function;
see question <a href="faqcat973e.html?sec=fp#complex">14.11</a> for an example.
</p><p>C99 introduces ``compound literals'',
one form of which
provides for
structure constants.
For example, to pass a constant coordinate pair
to a
hypothetical
<TT>plotpoint</TT> function
which expects a <TT>struct&nbsp;point</TT>,
you can call
<pre>
	plotpoint((struct point){1, 2});
</pre>
Combined with ``designated initializers''
(another C99 feature),
it is also possible to specify member values by name:
<pre>
	plotpoint((struct point){.x=1, .y=2});
</pre>
</p><p>See also question <a href="faqcatabdc.html?sec=ptrs#refconst">4.10</a>.
</p>

<p>References:

C9X Sec. 6.3.2.5, Sec. 6.5.8
<hr><hr><hr>
<a name="io">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/io.html"><!-- qtag -->Question 2.11</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can I read/write structures from/to

data files?

</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It is relatively straightforward
to write a structure
out
using <TT>fwrite</TT>:
<pre>
	fwrite(&amp;somestruct, sizeof somestruct, 1, fp);
</pre>

and a corresponding
<TT>fread</TT> invocation can read it back in.
What happens here is that
<TT>fwrite</TT> receives a pointer to the structure,
and writes
(or <TT>fread</TT> correspondingly reads)
the memory image of the structure
as a stream of bytes.
The <TT>sizeof</TT> operator determines
how many bytes the structure occupies.
</p><p>(The
call to <TT>fwrite</TT> above is correct
under an ANSI compiler
as long as a prototype for <TT>fwrite</TT> is in scope,
usually because <TT>&lt;stdio.h&gt;</TT> is <TT>#include</TT>d.
</p><p>However,
data files
written
as memory images
in this way
will
<em>not</em>
be
portable,
particularly
if they contain floating-point fields or pointers.
The memory layout of structures is
machine and
compiler dependent.
Different compilers may use different amounts of padding
(see question <a href="faqcat6b6b.html?sec=struct#padding">2.12</a>),
and
the sizes and byte orders of fundamental types
vary across machines.
Therefore,
structures written as memory images
cannot necessarily be read back in
by programs running on other machines
(or even compiled by other compilers),
and this is an
important concern if
the data files you're writing
will ever be interchanged between machines.
See also

questions
<a href="faqcat6b6b.html?sec=struct#padding">2.12</a>
and
<a href="faqcat38c2.html?sec=misc#binaryfiles">20.5</a>.
</p><p>Also,
if the structure contains any pointers
(<TT>char&nbsp;*</TT> strings,
or pointers to other data structures),
only the pointer values will be written,
and they are most unlikely to be valid when read back in.
Finally,
note
that
for widespread portability
you must use the <TT>"b"</TT> flag
when opening the files;
see question <a href="faqcat1d60.html?sec=stdio#fopenbinary">12.38</a>.
</p><p>A more portable solution,
though it's a bit more work initially,
is to write a pair of functions
for writing and reading a structure,
field-by-field,
in a portable
(perhaps even human-readable)
way.

</p>
<p>References:

H&amp;S Sec. 15.13 p. 381
<hr><hr><hr>
<a name="padding">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/padding.html"><!-- qtag -->Question 2.12</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why is my
compiler
leaving holes in structures,
wasting space
and preventing

``binary'' I/O to external data
files?
Can
I turn
this
off,
or otherwise control the alignment of structure fields?

</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Many machines
access values in memory
most efficiently
when the values are appropriately aligned.
(For example,
on a byte-addressed machine,
<TT>short&nbsp;int</TT>s of size 2
might best be placed at even addresses,
and
<TT>long&nbsp;int</TT>s of size 4
at addresses which are a multiple of 4.)
Some machines cannot perform unaligned accesses
at all,
and
<em>require</em> that
all data
be appropriately aligned.
</p><p>Therefore, if you declare a structure like
<pre>
	struct {
		char c;
		int i;
	};
</pre>
the compiler will usually
leave an unnamed, unused hole
between the <TT>char</TT> and <TT>int</TT> fields,
to ensure that the

<TT>int</TT> field
is properly aligned.
(This incremental alignment of the second field
based on the first
relies on the fact
that the structure itself
is always properly aligned,
with the most conservative

alignment requirement.
The compiler guarantees this alignment for structures it allocates,
as does <TT>malloc</TT>.)
</p><p>Your compiler may provide an extension to give you
control
over the packing of structures
(i.e. whether they are padded or not),
perhaps
with
a <TT>#pragma</TT> (see
question <a href="faqcat7d4b.html?sec=ansi#pragma">11.20</a>),
but there
is no standard method.
</p><p>If you're worried about wasted space,
you can minimize the effects of padding
by ordering the members of
a
structure


based on their base types,
from largest to smallest.

You can sometimes get more control over size and alignment
by using bit-fields,
although they
have their own drawbacks.
(See question <a href="faqcat6b6b.html?sec=struct#bitfields">2.26</a>.)
</p><p>See also
questions <a href="faqcat6b6b.html?sec=struct#endpad">2.13</a>, <a href="faqcat5e04.html?sec=strangeprob#ptralign">16.7</a>, and <a href="faqcat38c2.html?sec=misc#binaryfiles">20.5</a>.

</p><p>Additional links:
<br>
<br>
A bit more




<a href="faqcat6b6b.html?sec=struct#align">explanation of ``alignment''</a>
and why it requires paddding
<br>
<br>
Additional
<a href="../../struct/align.esr.html">ideas on working with alignment and padding</a>
by Eric Raymond,
couched in the form of six new FAQ list questions
<br>
<br>
Corrections to the above from
<a href="../../struct/align.esr2.html">Norm Diamond</a>
and
<a href="../../struct/align.esr3.html">Clive Feather</a>
</p>

<p>References:

K&amp;R2 Sec. 6.4 p. 138
<br>
H&amp;S Sec. 5.6.4 p. 135
<hr><hr><hr>
<a name="endpad">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/endpad.html"><!-- qtag -->Question 2.13</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why does <TT>sizeof</TT> report a larger size than I expect for a
structure type,
as if there were padding at the end?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Padding at the end of a structure may be necessary
to preserve alignment

when an array of contiguous structures is allocated.



Even
when
the structure is not part of an array,
the
padding remains,
so that <TT>sizeof</TT> can always return a consistent

size.

See also question
<a href="faqcat6b6b.html?sec=struct#padding">2.12</a>.
</p>
<p>References:

H&amp;S Sec. 5.6.7 pp. 139-40
<hr><hr><hr>
<a name="offsetof">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/offsetof.html"><!-- qtag -->Question 2.14</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can I determine the byte offset of a field within a structure?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
ANSI C defines the <TT>offsetof()</TT> macro
in <TT>&lt;stddef.h&gt;</TT>,

which lets you compute
the offset of field <TT>f</TT> in struct <TT>s</TT>
as
<TT>offsetof(struct&nbsp;s,&nbsp;f)</TT>.
If for some reason you have to code this sort of thing yourself,
one possibility is
<pre>
	#define offsetof(type, f) ((size_t) \
		((char *)&amp;((type *)0)-&gt;f - (char *)(type *)0))
</pre>
</p><p>This implementation is not 100% portable;
some compilers may legitimately refuse to accept it.
</p><p>(The complexities

of
the definition above
bear a bit of explanation.

The subtraction of a carefully converted null pointer



is
supposed
to guarantee
that a simple offset is computed
even if the internal representation of the null pointer
is not 0.
The casts to <TT>(char&nbsp;*)</TT> arrange
that the offset
so computed
is a byte offset.
The nonportability is in pretending,
if only for the purposes of address calculation,
that there is an instance of the <TT>type</TT> sitting at address 0.
Note, however,
that since the pretend instance is not actually referenced,
an access violation is unlikely.)
</p>



<p>References:

ISO Sec. 7.1.6
<br>
Rationale Sec. 3.5.4.2
<br>
H&amp;S Sec. 11.1 pp. 292-3
<hr><hr><hr>
<a name="fieldnames">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/fieldnames.html"><!-- qtag -->Question 2.15</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can I access structure fields by name at run time?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Keep track
of the field
offsets as computed

using the <TT>offsetof()</TT> macro
(see question <a href="faqcat6b6b.html?sec=struct#offsetof">2.14</a>).
If <TT>structp</TT> is a pointer to
an instance of the structure,
and field <TT>f</TT> is an <TT>int</TT>
having offset <TT>offsetf</TT>,
<TT>f</TT>'s value can be set indirectly with
<pre>