faqcat7d4b.html

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

<pre>
	extern int f1();
	extern int f2();
	int main(argc, argv) int argc; char **argv; { ... }
	int f3() { ... }
</pre>

(Beware
of parameters with ``narrow'' types;
see question <a href="faqcat7d4b.html?sec=ansi#argpromos">11.3</a>.)
<li>Replace <TT>void *</TT> with <TT>char *</TT>
.
<li>Perhaps insert explicit casts where converting between
``generic'' pointers
(<TT>void&nbsp;*</TT>, which you've just replaced with <TT>char&nbsp;*</TT>)
and other pointer types
(for instance in calls to <TT>malloc</TT> and <TT>free</TT>,
and in <TT>qsort</TT> comparison functions;
see questions <a href="faqcatbafd.html?sec=malloc#cast">7.7</a> and <a href="faqcat1067.html?sec=lib#qsort2">13.9</a>).
<li>


Insert casts when passing the ``wrong'' numeric
types as function arguments, e.g. <TT>sqrt((double)i);</TT>.
<li>
Rework calls to <TT>realloc</TT>
that use <TT>NULL</TT> or <TT>0</TT> as first or second arguments
(see question <a href="faqcatbafd.html?sec=malloc#reallocnull">7.30</a>).
<li>Remove <TT>const</TT> and <TT>volatile</TT> qualifiers.
<li>Modify any initialized automatic aggregates
(see question <a href="faqcatd3c2.html?sec=decl#autoaggrinit">1.31</a>).
<li>Use older library functions
(see question <a href="faqcat1067.html?sec=lib#oldlibfcns">13.24</a>).

<li>Re-work any preprocessor macros involving <TT>#</TT> or <TT>##</TT>
(see questions <a href="faqcat204f.html?sec=cpp#oldpaste">10.20</a>, <a href="faqcat204f.html?sec=cpp#charize">10.21</a>,
and <a href="faqcat7d4b.html?sec=ansi#macstrexp">11.18</a>).
<li>
Rework conditional compilation
involving <TT>#elif</TT>.
<li>Convert from the facilities of <TT>&lt;stdarg.h&gt;</TT>
to <TT>&lt;varargs.h&gt;</TT>
(see question <a href="faqcat744e.html?sec=varargs#oldvarargs">15.7</a>).
<li>Cross your fingers.
(In other words, the
steps listed here
are not always
sufficient;
more complicated changes may be required which aren't covered 
by any cookbook conversions.)
</OL><p>It is possible to make many of these changes with the preprocessor
rather than by editing source code.







</p><p>See also the
Rationale's list of ``quiet changes''
(see question <a href="faqcat7d4b.html?sec=ansi#avail">11.2</a>).
</p><p>See also question <a href="faqcat7d4b.html?sec=ansi#cproto">11.31</a>.
<hr><hr><hr>
<a name="preansi2">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/preansi2.html"><!-- qtag -->Question 11.29b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What does the message

``Automatic aggregate intialization is an ANSI feature''
mean?
My compiler is complaining about valid ANSI code.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Messages like these are typically emitted by pre-ANSI compilers
which have been upgraded just enough to detect
(but not properly translate)
new C features which were introduced with the ANSI Standard.
The implication of the message is that you should pay your vendor more money
for a copy of their real ANSI C compiler.
<hr><hr><hr>
<a name="preansilib">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/preansilib.html"><!-- qtag -->Question 11.30</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why are some ANSI/ISO Standard library functions showing up as
undefined, even though I've got an ANSI compiler?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It's possible


to have a compiler available which accepts ANSI syntax,
but not to have

ANSI-compatible header files

or run-time libraries installed.
(In fact,
this situation is rather common when using
a non-vendor-supplied compiler such as <TT>gcc</TT>.)
See also questions
<a href="faqcat7d4b.html?sec=ansi#preansi">11.29a</a>,
<a href="faqcat1067.html?sec=lib#extlibs">13.25</a>,
and
<a href="faqcat1067.html?sec=lib#libsearch">13.26</a>.
<hr><hr><hr>
<a name="cproto">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/cproto.html"><!-- qtag -->Question 11.31</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Does anyone have a tool for converting old-style C programs to
ANSI C,
or vice versa,
or for automatically generating prototypes?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Two programs, protoize and unprotoize,
convert back and forth between prototyped and ``old
style'' function definitions and declarations.
(These programs do
<em>not</em>
handle full-blown translation between
``Classic''&nbsp;C
and ANSI C.)
These programs


are part of
the FSF's GNU C compiler distribution;

see question <a href="faqcatccbd.html?sec=resources#compilers">18.3</a>.
</p><p>




The unproto program
(/pub/unix/unproto5.shar.Z on ftp.win.tue.nl)
is a filter which sits between the preprocessor
and the next compiler pass,
converting most of ANSI C to traditional C on-the-fly.
</p><p>The GNU GhostScript package comes with
a little program called ansi2knr.
</p><p>Before converting ANSI C back to old-style,
beware that such a conversion cannot always be made both safely 
and automatically.
ANSI C introduces
new features and complexities
not found in K&amp;R C.
You'll especially need to be

careful of prototyped function calls;
you'll probably need to insert explicit casts.
See also questions <a href="faqcat7d4b.html?sec=ansi#argpromos">11.3</a> and 
<a href="faqcat7d4b.html?sec=ansi#preansi">11.29a</a>.
</p><p>Several prototype generators exist,
many as modifications to <TT>lint</TT>.



A program called
CPROTO was posted to comp.sources.misc in March, 1992.


There is another program called ``cextract.''


Many vendors supply simple utilities
like these
with their compilers.
See also
question
<a href="faqcatccbd.html?sec=resources#sources">18.16</a>.
(But
be careful
when generating prototypes for old functions
with ``narrow'' parameters;
see
question
<a href="faqcat7d4b.html?sec=ansi#argpromos">11.3</a>.)
</p>
<hr><hr><hr>
<a name="extensions">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/extensions.html"><!-- qtag -->Question 11.32</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why won't
the Frobozz Magic C Compiler,
which claims to be ANSI compliant,
accept this code?
I know that the code is ANSI, because <TT>gcc</TT> accepts it.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Many
compilers support a few non-Standard extensions,
<TT>gcc</TT> more so than most.

Are you sure that the code being rejected doesn't rely on
such an
extension?



The compiler may have an option to disable extensions;
it may be wise to use such an option
if you're not certain your code is ANSI-compatible.
(<TT>gcc</TT>, to its credit,
includes a <TT>-pedantic</TT> option
which turns off extensions
and attempts to enforce strict ANSI compliance.)
</p><p>It is usually a bad idea



to perform
experiments with a particular compiler
to determine properties of a language;

the applicable

standard may permit variations,
or the compiler may be wrong.
See also question
<a href="faqcat7d4b.html?sec=ansi#experiment">11.35</a>.
<hr><hr><hr>
<a name="undef">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/undef.html"><!-- qtag -->Question 11.33</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
People seem to make a point of distinguishing
between
implementation-defined,
unspecified,
and
undefined
behavior.
What do these mean?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
First of all,
all

three of these represent areas
in which the C Standard
does <em>not</em> specify exactly what a particular construct,
or a program which uses it,
must do.
This looseness in C's definition is traditional and deliberate:
it permits compiler writers to
(a)
make

choices
which allow efficient code to be generated
by arranging that various constructs
are implemented as ``however the hardware does them''
(see also question <a href="faqcat973e.html?sec=fp#strangefp">14.4a</a>),
and
(b)
ignore
(that is,
avoid worrying about
generating correct code for)
certain marginal constructs
which are
too difficult to define precisely
and which probably aren't useful to well-written programs anyway
(see for example
the code fragments in
questions
<a href="faqcatee08.html?sec=expr#evalorder1">3.1</a>,
<a href="faqcatee08.html?sec=expr#evalorder2">3.2</a>,
and
<a href="faqcatee08.html?sec=expr#ieqiplusplus">3.3</a>).
</p><p>These three variations on
``not precisely defined by the standard''
are defined as:
</p><p><b>implementation-defined:</b>
The implementation must pick some behavior;
it may not fail to compile the program.
(The program using the construct is not incorrect.)
The choice must be documented.
The Standard may specify
a set of allowable behaviors
from which to choose,
or it may impose no particular requirements.
</p><p><b>unspecified:</b>
Like implementation-defined,
except that the choice need not be documented.
</p><p><b>undefined:</b>
Anything at all can happen;
the Standard imposes no requirements.
The program may fail to compile,
or it may execute incorrectly
(either crashing or silently generating incorrect results),
or it may fortuitously do exactly what the programmer intended.
</p><p>Note, too,
that since the Standard imposes
absolutely no
requirements
on the behavior of a compiler faced with an instance of undefined behavior,
the compiler
(more importantly, any generated code)
can do absolutely anything.
In particular,
there is no guarantee
that
at most
the undefined bit of the program will behave badly,
and
that the rest of the program will perform normally.
It's perilous
to think that you can tolerate undefined behavior
in a
program,
imagining that its undefinedness can't hurt;
the undefined behavior can be more undefined than you think it can.
(See
question <a href="faqcatee08.html?sec=expr#evalorder2">3.2</a>
for a relatively simple

example.)
</p><p>Since many people seem to have trouble
comprehending the depths to which undefined behavor can descend,

it is traditional to come up with eye-catching, outrageous examples.
Undefined means that,
notwithstanding question <a href="faqcate034.html?sec=bool#bool2">9.2</a>,
<TT>printf("%d",&nbsp;j++&nbsp;&lt;=&nbsp;j);</TT>
can print 42, or ``forty-two.''


</p><p>If you're
interested in
writing portable code,
you can
ignore the distinctions,
as you'll
usually
want to avoid code that depends on any of the three behaviors.
</p><p>See also questions
<a href="faqcatee08.html?sec=expr#evalorder4">3.9</a>,
and
<a href="faqcat7d4b.html?sec=ansi#appalled">11.34</a>.
</p><p>(A fourth defined class of not-quite-precisely-defined behavior,
without the same stigma attached to it,
is <a href="../../sx1/index.html#locale-specific"><dfn>locale-specific</dfn></a>.)
</p>




<p>References:

ISO Sec. 3.10, Sec. 3.16, Sec. 3.17
<br>
Rationale Sec. 1.6
<hr><hr><hr>
<a name="compliance">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/compliance.html"><!-- qtag -->Question 11.33b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What does it really mean for a program to be
``legal''
or
``valid''
or
``conforming''?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Simply stated,
the
Standard talks about three
kinds of conformance:
conforming programs,
strictly conforming programs,
and
conforming implementations.
</p><p>A <a href="../../sx1/index.html#conforming program"><dfn>conforming program</dfn></a> is one that is accepted by
a
conforming implementation.
</p><p>A <a href="../../sx1/index.html#strictly conforming program"><dfn>strictly conforming program</dfn></a> is one that
does not depend on
any implementation-defined, unspecified, or undefined behavior,
that does not exceed any implementation limits,
and that otherwise uses
only the features of the language and library
as specified in the Standard.
</p><p>A <a href="../../sx1/index.html#conforming implementation"><dfn>conforming implementation</dfn></a> is one that does everything the
Standard says it's supposed to.
(The way the Standard says this is that
a conforming implementation ``shall accept
any strictly conforming program''.)
There are two kinds of conforming implementation:
hosted and freestanding.
A <a href="../../sx1/index.html#hosted implementation"><dfn>hosted implementation</dfn></a> is intended for use with conventional
application programs;
a <a href="../../sx1/index.html#freestanding implementation"><dfn>freestanding implementation</dfn></a> is intended for use with
embedded systems and the like,
and is not required to supply all of the standard library functions.
</p><p>Unfortunately,
neither of
the definitions relating to conforming programs are
as practically useful as one might wish.
There are very few
realistic, useful, strictly conforming programs.
On the other hand, a
merely conforming program can make use of any compiler-specific
extension it wants to.
</p><p>Other words you may hear are
``compliant'' and ``conformant''
which are basically
just synonyms for
``conforming''.
</p>

<p>References:

ISO Sec. 
<br>
Rationale Sec. 1.7
<hr><hr><hr>
<a name="appalled">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/appalled.html"><!-- qtag -->Question 11.34</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I'm appalled that the ANSI Standard leaves so many issues undefined.
Isn't a Standard's whole job to standardize these things?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It has always been a characteristic of C that certain
constructs behaved



in whatever way
a particular compiler
or a particular piece of hardware
chose to implement them.
This deliberate imprecision
often
allows compilers to generate
more efficient code for common cases,
without having to burden all programs
with
extra code to
assure well-defined behavior
of cases deemed to be less reasonable.
Therefore,
the Standard is simply codifying existing practice.
</p><p>A programming language standard can be thought of
as a treaty between the
language user
and the
compiler implementor.
Parts of that treaty consist of
features which the compiler implementor agrees to provide,
and which the user may assume will be available.
Other parts, however,
consist of rules which the user agrees to follow
and which the implementor may assume will be followed.
As long as both sides uphold their guarantees,
programs have a fighting chance of working correctly.
If <em>either</em> side reneges on any of its commitments,
nothing is guaranteed to work.

</p><p>See also
questions <a href="faqcat7d4b.html?sec=ansi#experiment">11.35</a> and <a href="faqcatea63.html?sec=osdep#sysdep">19.42</a>.


</p>
<p>References:

Rationale Sec. 1.1
<hr><hr><hr>
<a name="experiment">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/experiment.html"><!-- qtag -->Question 11.35</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
People keep saying that the behavior
of <TT>i&nbsp;=&nbsp;i++</TT>
is undefined,
but
I just tried
it
on an ANSI-conforming compiler,
and got the results I expected.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
A compiler may do anything it likes when faced with undefined
behavior
(and, within limits, with implementation-defined and
unspecified behavior),
including doing what you expect.
It's unwise to depend on it, though.
</p><p>Here is another way of looking at it,

due to Roger Miller:


<blockquote>``Somebody told me that in basketball
you can't hold the ball and run.
I got a basketball and tried it and it worked just fine.
He obviously didn't understand basketball.''
</blockquote></p><p>See also
questions <a href="faqcatbafd.html?sec=malloc#lucky">7.3b</a>, <a href="faqcat7d4b.html?sec=ansi#extensions">11.32</a>, <a href="faqcat7d4b.html?sec=ansi#undef">11.33</a>, and <a href="faqcat7d4b.html?sec=ansi#appalled">11.34</a>.
<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcat204f.html?sec=cpp" rev=precedes>prev</a>
<a href="faqcat1d60.html?sec=stdio" 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="../../ansi/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=ansi by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:58:05 GMT -->
</html>