faqcat5e04.html

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

<TT>printf</TT> format
and arguments,
especially trying to print <TT>long&nbsp;int</TT>s using <TT>%d</TT>
(see
questions <a href="faqcat1d60.html?sec=stdio#printftypes">12.7</a> and <a href="faqcat1d60.html?sec=stdio#scanfvsprintf">12.9</a>)
<li>
trying to
allocate



more memory than an <TT>unsigned&nbsp;int</TT> can count,
especially on machines with limited memory
(see also questions <a href="faqcatbafd.html?sec=malloc#sizewrap">7.16</a>
and <a href="faqcatea63.html?sec=osdep#bigdatastr">19.23</a>)
<li>array bounds problems,
especially of small, temporary
buffers,
perhaps used for constructing strings with <TT>sprintf</TT>
<a href="../../strangeprob/gonzo.html" rel=subdocument>[footnote]</a>
(see also
questions <a href="faqcatbafd.html?sec=malloc#malloc1">7.1</a>, <a href="faqcat1d60.html?sec=stdio#sprintfsize">12.21</a>, and <a href="faqcatea63.html?sec=osdep#system2">19.28</a>)
<li>invalid assumptions about the mapping of <TT>typedef</TT>s,
especially <TT>size_t</TT>
(see question <a href="faqcatbafd.html?sec=malloc#sizetlong">7.15</a>)
<li>floating point problems
(see questions <a href="faqcat973e.html?sec=fp#printfprec">14.1</a> and <a href="faqcat973e.html?sec=fp#strangefp">14.4a</a>)
<li>


anything you thought was a clever exploitation
of the
way you believe code is generated for your
specific
system
</UL></p><p>Proper use of
function prototypes
can catch several of these problems;
<TT>lint</TT> would catch several more.
See also questions 
<a href="faqcat5e04.html?sec=strangeprob#biglocal">16.3</a>,
<a href="faqcat5e04.html?sec=strangeprob#crashatexit">16.4</a>,
and
<a href="faqcatccbd.html?sec=resources#lint1">18.4</a>.
<hr><hr><hr>
<a name="strlitnomod">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../strangeprob/strlitnomod.html"><!-- qtag -->Question 16.6</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why does
this code:
<pre>
char&nbsp;*p&nbsp;=&nbsp;"hello,&nbsp;world!";
p[0]&nbsp;=&nbsp;'H';</pre>

crash?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>

String constants
are
in fact
constant.
The compiler may
place them in nonwritable storage,
and it is therefore not safe to modify
them.

When you need writable strings,
you must allocate writable memory for them,
either by declaring an array,
or by calling <TT>malloc</TT>.
Try
<pre>
	char a[] = "hello, world!";
</pre>
</p><p>By the same argument,
a typical invocation of the old Unix <TT>mktemp</TT> routine
<pre>
	char *tmpfile = mktemp("/tmp/tmpXXXXXX");
</pre>
is nonportable;
the proper usage is
<pre>
	char tmpfile[] = "/tmp/tmpXXXXXX";
	mktemp(tmpfile);
</pre>
</p><p>See also question <a href="faqcatd3c2.html?sec=decl#strlitinit">1.32</a>.
</p>

<p>References:

ISO Sec. 6.1.4
<br>
H&amp;S Sec. 2.7.4 pp. 31-2
<hr><hr><hr>
<a name="ptralign">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../strangeprob/ptralign.html"><!-- qtag -->Question 16.7</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I've got some code that's trying to unpack external structures, 
but it's crashing
with a message about an ``unaligned access.''
What does this mean?
The code looks like this:
<pre>
struct mystruct {
	char c;
	long int i32;
	int i16;
} s;

char buf[7], *p;
fread(buf, 7, 1, fp);
p = buf;
s.c = *p++;
s.i32 = *(long int *)p;
p += 4;
s.i16 = *(int *)p;
</pre>
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The problem is that you're playing too fast and loose with 
your

pointers.
Some machines require that data values be stored at 
appropriately aligned addresses.
For instance,
two-byte <TT>short&nbsp;int</TT>s
might be constrained to sit at even addresses,
and four-byte <TT>long&nbsp;int</TT>s at multiples of four.
(See also question <a href="faqcat6b6b.html?sec=struct#padding">2.12</a>.)
By converting a <TT>char&nbsp;*</TT>
(which can point to any byte)
to an <TT>int&nbsp;*</TT> or <TT>long&nbsp;int&nbsp;*</TT>,
and then indirecting

on it,
you
can end up
asking the
processor to
fetch a
multibyte
value from an unaligned
address,
which it isn't willing to do.
</p><p>A better way to unpack
external structures
is with code like

<pre>
	unsigned char *p = buf;

	s.c = *p++;

	s.i32 = (long)*p++ &lt;&lt; 24;
	s.i32 |= (long)*p++ &lt;&lt; 16;
	s.i32 |= (unsigned)(*p++ &lt;&lt; 8);
	s.i32 |= *p++;

	s.i16 = *p++ &lt;&lt; 8;
	s.i16 |= *p++;
</pre>
</p><p>This code
also gives you control over byte order.
(This example,
though,
assumes
that a <TT>char</TT> is 8 bits,
and that the <TT>long&nbsp;int</TT> and <TT>int</TT>
being unpacked from the ``external structure''
are 32 and 16 bits, respectively.)

See question <a href="faqcat1d60.html?sec=stdio#extconform">12.42</a>
(which contains some similar code)
for a few explanations
and caveats.
</p><p>See also question <a href="faqcatabdc.html?sec=ptrs#castincr">4.5</a>.
</p>


<p>References:

ISO Sec. 6.3.3.2, Sec. 6.3.4
<br>
H&amp;S Sec. 6.1.3 pp. 164-5
<hr><hr><hr>
<a name="segv">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../strangeprob/segv.html"><!-- qtag -->Question 16.8</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What
do
``Segmentation violation'',
``Bus error'',
and
``General protection fault''
mean?
What's a ``core dump''?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>

These
symptoms
(and
any similar messages
having to do with
memory access violations or protection faults)
generally
mean
that your program tried to access memory it shouldn't
have,

invariably
as a result of
stack corruption
or
improper pointer use.
Likely causes are:
<UL><li>overflow of local
(``automatic,'' stack-allocated)
arrays
<li>inadvertent use of null pointers
(see also questions <a href="faqcat1f1a.html?sec=null#null2">5.2</a> and <a href="faqcat1f1a.html?sec=null#nullpassign">5.20</a>)
<li>uninitialized,
misaligned,
or otherwise
improperly allocated

pointers
(see
questions <a href="faqcatbafd.html?sec=malloc#malloc1">7.1</a>, <a href="faqcatbafd.html?sec=malloc#malloc2">7.2</a>, and <a href="faqcat5e04.html?sec=strangeprob#ptralign">16.7</a>)
<li>stale aliases to memory that has been relocated
(see question <a href="faqcatbafd.html?sec=malloc#realloc">7.29</a>)
<li>corruption of the
<TT>malloc</TT> arena
(see question
<a href="faqcatbafd.html?sec=malloc#crash">7.19</a>)
<li>attempts to modify read-only values
(those declared <TT>const</TT>,
and string literals--see question <a href="faqcatd3c2.html?sec=decl#strlitinit">1.32</a>)
<li>mismatched function arguments,
especially involving pointers;
two
possibilities are
<TT>scanf</TT>
(see question
<a href="faqcat1d60.html?sec=stdio#scanf1">12.12</a>)
and



<TT>fprintf</TT>
(make sure it receives its first
<TT>FILE&nbsp;*</TT> argument)
</UL></p><p>Under Unix,
any of these problems almost invariably leads to
a ``core dump'':
a file
named <TT>core</TT>,
<a href="../../strangeprob/ferrite.html" rel=subdocument>[footnote]</a>
created in the current directory,
containing a memory image of the crashed process,
for debugging.
</p><p>The distinction between
``Bus error'' and ``Segmentation Violation''
may or may not be significant;
different versions of Unix generate these
signals
under different sets of circumstances.
Roughly speaking,
a segmentation violation
indicates an attempt to access memory which doesn't even exist,
and a bus error
indicates an attempt to access memory in an illegal way
(perhaps due to an unaligned pointer;
see question <a href="faqcat5e04.html?sec=strangeprob#ptralign">16.7</a>).

</p><p>See also questions <a href="faqcat5e04.html?sec=strangeprob#biglocal">16.3</a>
and
<a href="faqcat5e04.html?sec=strangeprob#crashatexit">16.4</a>.
<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcat744e.html?sec=varargs" rev=precedes>prev</a>
<a href="faqcataae2.html?sec=style" rel=precedes>next</a>
<a href="faqcat.html" rev=subdocument>up</a>
</p>
<hr>
<p>
<br><!-- lastfooter -->
<a href="../../about.html">about this FAQ list</a>
&nbsp;
<a href="../../eskimo.html">about eskimo</a>
&nbsp;
<a href="../../search.html">search</a>
&nbsp;
<a href="../../feedback.html">feedback</a>
&nbsp;
<a href="../../strangeprob/copyright.html">copyright</a>
<p>
Hosted by
<a href="http://www.eskimo.com/"><img src="../../../www.eskimo.com/img/link/eskitiny.gif" alt="Eskimo North"></a>
</body>

<!-- Mirrored from c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=strangeprob by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:58:22 GMT -->
</html>