First, make sure that you have #included <math.h>, and correctly
	declared other functions returning double.
If the problem isn't that simple, recall that most digital computers use floating-point formats which provide a close but by no means exact simulation of real number arithmetic. Underflow, cumulative precision loss, and other anomalies are often troublesome.
Don't assume that floating-point results will be exact, and especially don't assume that floating-point values can be compared for equality. (Don't throw haphazard "fuzz factors" in, either.)
These problems are no worse for C than they are for any other computer language. Floating-point semantics are usually defined as "however the processor does them;" otherwise a compiler for a machine without the "right" model would have to do prohibitively expensive emulations.
This article cannot begin to list the pitfalls associated with, and workarounds appropriate for, floating-point work. A good programming text should cover the basics.
References: EoPS Sec. 6 pp. 115-8.
<math.h>,
	but I keep getting "undefined: _sin" compilation errors.
  	Make sure you're linking with the correct math library.  For
	instance, under Unix, you usually need to use the -lm option,
	and at the end of the command line, when compiling/linking.
        See also question 12.14.
  	Because few processors have an exponentiation instruction.
	Instead, you can #include <math.h> and use the pow() function,
	although explicit multiplication is often better for small
	positive integral exponents.
References: ANSI Sec. 4.5.5.1 .
The simplest and most straightforward way is with code like
        (int)(x + 0.5)
This won't work properly for negative numbers, though.
Many systems with high-quality IEEE floating-point implementations provide facilities (e.g. an isnan() macro) to deal with these values cleanly, and the Numerical C Extensions Group (NCEG) is working to formally standardize such facilities. A crude but usually effective test for NaN is exemplified by
        #define isnan(x) ((x) != (x))
although non-IEEE-aware compilers may optimize the test away.
  	Some compilers for small machines, including Turbo C (and
	Ritchie's original PDP-11 compiler), leave out floating point
	support if it looks like it will not be needed.  In particular,
	the non-floating-point versions of printf and scanf save space
	by not including code to handle %e, %f, and %g.  It happens that
	Turbo C's heuristics for determining whether the program uses
	floating point are insufficient, and the programmer must
	sometimes insert an extra, explicit call to a floating-point
	library routine to force loading of floating-point support.