C users must avoid using dangerous functions that do not check bounds
unless they've ensured that the bounds will never get exceeded.
Functions to avoid in most cases (or ensure protection) include
the functions strcpy(3), strcat(3), sprintf(3)
(with cousin vsprintf(3)), and gets(3).
These should be replaced with functions such as strncpy(3), strncat(3),
snprintf(3), and fgets(3) respectively, but see the discussion below.
The function strlen(3) should be avoided unless you can ensure that there
will be a terminating NIL character to find.
The scanf() family (scanf(3), fscanf(3), sscanf(3), vscanf(3),
vsscanf(3), and vfscanf(3)) is often dangerous to use; do not use it
to send data to a string without controlling the maximum length
(the format %s is a particularly common problem).
Other dangerous functions that may permit buffer overruns (depending on their
use) include
realpath(3), getopt(3), getpass(3),
streadd(3), strecpy(3), and strtrns(3).
You must be careful with getwd(3); the buffer sent to getwd(3) must be
at least PATH_MAX bytes long.
The select(2) helper macros
FD_SET(), FD_CLR(), and FD_ISSET() do not check that the index fd
is within bounds; make sure that fd >= 0 and fd <= FD_SETSIZE
(this particular one has been exploited in pppd).

Unfortunately, snprintf()’s variants have additional problems.
Officially, snprintf() is not a standard C function in the ISO 1990
(ANSI 1989) standard, though sprintf() is,
so some very old systems do not include snprintf().
Even worse, some systems’ snprintf() do not actually protect
against buffer overflows; they just call sprintf directly.
Old versions of Linux’s libc4 depended on a “libbsd” that did this
horrible thing, and I’m told that some old HP systems did the same.
Linux’s current version of snprintf is known to work correctly, that is, it
does actually respect the boundary requested.
The return value of snprintf() varies as well;
the Single Unix Specification (SUS) version 2
and the C99 standard differ on what is returned by snprintf().
Finally, it appears that at least some versions of
snprintf don’t guarantee that its string will end in NIL; if the
string is too long, it won’t include NIL at all.
Note that the glib library (the basis of GTK, and not the same as the
GNU C library glibc) has a g_snprintf(), which
has a consistent return semantic, always NIL-terminates, and
most importantly always respects the buffer length.

Of course, the problem is more than just calling string functions poorly.
Here are a few additional examples of types of buffer overflow problems,
graciously suggested by Timo Sirainen, involving manipulation of
numbers to cause buffer overflows.

First, there’s the problem of signedness.
If you read data that affects the buffer size,
such as the "number of characters to be read,"
be sure to check if the number is less than zero or one.
Otherwise, the negative number may be cast to an unsigned number,
and the resulting large positive number
may then permit a buffer overflow problem.
Note that sometimes an attacker can provide a large positive number and
have the same thing happen;
in some cases, the large value will be interpreted as a negative number
(slipping by the check for large numbers if there’s no check
for a less-than-one value),
and then be interpreted later into a large positive value.

Here’s a second example identified by Timo Sirainen,
involving integer size truncation.
Sometimes the different sizes of integers
can be exploited to cause a buffer overflow.
Basically, make sure that you don’t truncate any integer results used to
compute buffer sizes.
Here’s Timo’s example for 64-bit architectures:

Here’s a third example from Timo Sirainen, involving integer overflow.
This is particularly nasty when combined with malloc(); an attacker
may be able to create a situation where the computed buffer size
is less than the data to be placed in it.
Here is Timo’s sample: