The most common modern systems *(programming language) to date, by
_(Brian Kernighan) and _(Dennis M. Ritchie) (K&R). It's low-level, and the typing is rather weak.

Many people build typing systems on top of C. _(C++) was at first an extensions of C via a cfront preprocessors/code generator. _(Objective-C) is derived from the GCC C compiler front end via the _(GCC AST Tree) interface. 

It is very typical in C to create function pointers, and tables of function pointers to build OO concepts. Objective C and C++ solidify the layout of these structures without changing the underlying language drastically.

_(C#) and _(Java) are more distant relatives of C that give you many more user definable types and other advanced language features are and somewhat backwards compatible.

Via the _(GCC AST Tree) it is possible to do full extension to C like languages and inject meta-level code.

The _(GNOME GLIB) for example builds an object layer on top of C with many interfaces to other languages.

See also <a href="http://www.wikipedia.org/wiki/C_language">the WIKIPedia entry for C</a>.

<P>
C is a low-level, weakly typed, static, non-modular, non-generic,
non-reflective language. It was designed in the late '70s as a portable
assembler for the PDP series (nominally compatible machines but with
various word lengths), and it is still the state of the art in that
area, although, as a systems programming language, it is more adapted to
the PDP-11 than to modern architectures. In the late '80s, the small and
elegant `K&R' C became the prey of an ANSI standards commitee; it is now
ANSI Standard C. In the '80s, C (in our opinion wrongly) became the
language of choice for general purpose programming. C offers absolutely
no particular interest when cut from all its standard compilers and
libraries, since you can no longer port existing software. As TUNES
won't support any standard C library (at least as support for native
code), and requires a different compiler anyway, because its semantics
is so much different, C offers no interest on top of TUNES. Thus, C just
has nothing to do with TUNES, except perhaps as a layer between TUNES
and a POSIX compliant system, if TUNES is to be implemented as an
application under such system (see the _(OTOP | TUNES On Top of POSIX) subproject).
</P>
<UL CLASS="links">
<LI><A HREF="http://www.cs.cf.ac.uk/Dave/C/">Programming in C</A> an online tutorial by Dave Marshall</LI>
<LI><A HREF="http://www.fermigier.com/fermigier/style.html.en">Programming Style</A> a collection of links about C and C++</LI>
<LI><A HREF="http://lclint.cs.virginia.edu/">Splint</A> if you must code in such a skanky language, we strongly recommend
you ensure the type safety of your programs.</LI>
</UL>
<UL CLASS="implementations">
<LI><A HREF="http://gcc.gnu.org">GCC</A>: the famous GNU Compiler Collection, formerly the GNU C Compiler</LI>
<LI><A HREF="http://www.cs.princeton.edu/software/lcc/">LCC</A>: a simpler alternative to GCC</li>
<LI><A HREF="http://www.intel.com/software/products/compilers/c60l/index.htm">The Intel C++ Compiler</A>: known to produce faster binaries than GCC.</LI>
</UL>
