C
{ We have a [1]C tutorial! ~drummyfish }
C is an [2]old [3]low level structured [4]statically typed [5]imperative
compiled [6]programming language, it is very fast and currently mostly
used by [7]less retarded software. Though by very strict standards it
would still be considered [8]bloated, compared to any mainstream [9]modern
language it is very bullshitless, [10]KISS and greatly established and
"culturally stable", so it is also the go-to language of the [11]suckless
community as well as most true experts, for example the [12]Linux and
[13]OpenBSD developers, because of its good, relatively simple design,
uncontested performance, wide support, great number of compilers, level of
control and a greatly established and tested status. C is perhaps the most
important language in history; it influenced, to smaller or greater
degree, basically all of the widely used languages today such as [14]C++,
[15]Java, [16]JavaScript etc., however it is not a thing of the past -- in
the area of low level programming C is still the number one unsurpassed
language. C is by no means perfect but it is currently probably the best
choice of a programming language (along with [17]comun, of course). Though
C is almost always compiled, there have appeared some C interpreters as
well.
{ See https://wiki.bibanon.org/The_Perpetual_Playthings. Also look up The
Ten Commandments for C Programmers by Henry Spencer. Also the Write in C
song (parody of Let it Be). ~drummyfish }
It is usually not considered an easy language to learn because of its low
level nature: it requires good understanding of how a [18]computer
actually works and doesn't prevent the programmer from shooting himself in
the foot. Programmer is given full control (and therefore responsibility).
There are things considered "tricky" which one must be aware of, such as
undefined behavior of certain operators and raw pointers. This is what can
discourage a lot of modern "coding monkeys" from choosing C, but it's also
what inevitably allows such great performance -- undefined behavior allows
the compiler to choose the most efficient implementation. On the other
hand, C as a language is pretty simple without [19]modern bullshit
concepts such as [20]OOP, it is not as much hard to learn but rather hard
to master, as any other true art. In any case you have to learn C even if
you don't plan to program in it regularly, it's the most important
language in history and lingua franca of programming, you will meet C in
many places and have to at least understand it: programmers very often use
C instead of [21]pseudocode to explain algorithms, C is used for
optimizing critical parts even in non-C projects, many languages compile
to C, it is just all around and you have to understand it like you have to
understand [22]English.
Some of the typical traits of C include great reliance on and utilization
of [23]preprocessor ([24]macros, the underlying C code is infamously
littered with "#ifdefs" all over the place which modify the code just
before compiling -- this is mostly used for compile-time configuration
and/or achieving better performance and/or for [25]portability),
[26]pointers (direct access to memory, used e.g. for memory allocation,
this is infamously related to "shooting oneself in the foot", e.g. by
getting [27]memory leaks) and a lot of [28]undefined behavior (many things
are purposefully left undefined in C to allow compilers to generate
greatly efficient code, but this sometimes lead to weird [29]bugs or a
program working on one machine but not another, so C requires some
knowledge of its specification). You can also infamously meet complicated
type declarations like void (*float(int,void (*n)(int)))(int), these are
frequently a subject of [30]jokes ("look, C is simple").
Unlike many "[31]modern" languages, C by itself doesn't offer too much
advanced functionality such as displaying graphics, working with network,
getting keyboard state and so on -- the base language doesn't even have
any [32]input/output, it's a pure processor of values in memory. The
standard library offers things like basic I/O with standard input/output
streams, basic operations with [33]files, strings, time, math functions
and other things, but for anything more advanced you will need an external
library like [34]SDL or [35]Posix libraries.
C is said to be a "[36]portable [37]assembly" because of its low level
nature, great performance etc. -- though C is structured (has control
structures such as branches and loops) and can be used in a relatively
high level manner, it is also possible to write assembly-like code that
operates directly with bytes in memory through [38]pointers without many
safety mechanisms, so C is often used for writing things like hardware
[39]drivers. On the other hand some restrain from likening C to assembly
because C compilers still perform many transformations of the code and
what you write is not necessarily always what you get.
Mainstream consensus acknowledges that C is among the best languages for
writing low level code and code that requires performance, such as
[40]operating systems, [41]drivers or [42]games. Even scientific libraries
with normie-language interfaces -- e.g. various [43]machine learning
[44]Python libraries -- usually have the performance critical core written
in [45]C. Normies will tell you that for things outside this scope C is
not a good language, with which we disagree -- [46]we recommend using C
for basically everything that's supposed to last, i.e. if you want to
write a good website, you should write it in C etc.
Is C low or high level? This depends on the context. Firstly back in the
day when most computers were programmed in [47]assembly, C was seen as
high level, simply because it offered the highest level of abstraction at
the time, while nowadays with languages like [48]Python and [49]JavaScript
around people see C as very low level by comparison -- so it really
depends on if you talk about C in context of "old" or "modern" programming
and which languages you compare it to. Secondly it also depends on HOW you
program in C -- you may choose to imitate assembly programming in C a lot,
avoid using libraries, touch hardware directly, avoid using complex
features and creating your own abstractions -- here you are really doing
low level programming. On the other hand you can emulate the "modern"
high-level style programming in C too, you can even mimic [50]OOP and make
it kind of "C++ with different syntax", you may use libraries that allow
you to easily work with strings, heavy macros that pimp the language to
some spectacular abomination, you may write your own garbage collector
etc. -- here you are basically doing high level programming in C.
[51]Fun: main[-1u]={1}; is a C [52]compiler bomb :) it's a short program
that usually makes the compiler produce a huge binary.
History and Context
C was developed in 1972 at [53]Bell Labs alongside the [54]Unix operating
system by [55]Dennis Ritchie and [56]Brian Kerninghan, as a successor to
the [57]B language ([58]portable language with [59]recursion) written by
Denis Ritchie and [60]Ken Thompson, which was in turn inspired by the the
[61]ALGOL language (code blocks, lexical [62]scope, ...). C was for a
while called NB for "new B". C was intimately interconnected with Unix and
its [63]hacker culture, both projects would continue to be developed
together, influencing each other. In 1973 Unix was rewritten in C. In 1978
Keninghan and Ritchie published a book called The C Programming Language,
known as K&R, which became something akin the C specification. In March
1987 [64]Richard Stallman along with others released the first version of
[65]GNU C compiler -- the official compiler of the [66]GNU project and the
compiler that would go on to become one of the most widely used. In 1989,
the [67]ANSI C standard, also known as C89, was released by the American
ANSI -- this is a very well supported and overall good standard. The same
standard was also adopted a year later by the international ISO, so C90
refers to the same language. In 1999 ISO issues a new standard that's
known as C99, still a very good standard embraced by [68]LRS. Later in
2011 and 2017 the standard was revised again to C11 and C17, which are
however no longer considered good.
Standards
C is not a single language, there have been a few standards over the years
since its inception in 1970s. The standard defines two major parts: the
base language and standard library. Notable standards and versions are:
* K&R C: C as described by its inventors in the book The C Programming
Language, before official standardization. This is kind of too ancient
nowadays.
* C89/C90 (ANSI/ISO C): First fully standardized version, usable even
today, many hardcore C programmers stick to this version so as to
enjoy maximum compiler support.
* C95: A minor update of the previous standard, adds wide character
support.
* C99: Updated standard from the year 1999, striking a nice balance
between "[69]modern" and "good old". This is a good version to use in
[70]LRS programs, but will be a little less supported than C89, even
though still very well supported. Notable new features against C89
include // comments, [71]stdint library (fixed-width integer types),
[72]float and long long type, variable length stack-allocated
[73]arrays, variadic [74]macros and declaration of variables
"anywhere" (not just at function start).
* C11: Updated standard from the year 2011. This one is too [75]bloated
and isn't worth using.
* C17/C18: Yet another update, yet more bloated and not worth using
anymore.
* ...
Quite nice online reference to all the different standards (including C++)
is available at https://en.cppreference.com/w/c/99.
[76]LRS should use C99 or C89 as the newer versions are considered
[77]bloat and don't have such great support in compilers, making them less
portable and therefore less free.
The standards of C99 and older are considered pretty [78]future-proof and
using them will help your program be future-proof as well. This is to a
high degree due to C having been established and tested better than any
other language; it is one of the oldest languages and a majority of the
most essential software is written in C, C compiler is one of the very
first things a new hardware platform needs to implement, so C compilers
will always be around, at least for historical reasons. C has also been
very well designed in a relatively minimal fashion, before the advent of
modern feature-creep and and bullshit such as [79]OOP which cripples
almost all "modern" languages.
Compilers
C is extreme well established, standardized and implemented so there is a
great number of C compilers around. Let us list only some of the more
notable ones.
* [80]gcc: The main "big name" that can compile all kinds of languages
including C, used by default in many places, very [81]bloated and can
take long to compile big programs, but is pretty good at
[82]optimizing the code and generating fast code. Also has number of
frontends and can compile for many platforms. Uses GENERIC/GIMPLE
[83]intermediate representation.
* [84]clang: Another big bloated compiler, kind of competes with gcc, is
similarly good at optimization etc. Uses [85]LLVM intermediate
representation.
* [86]tcc: Tiny C compiler, [87]suckless, orders of magnitude smaller
(currently around 25 KLOC) and simpler than gcc and clang, doesn't use
any intermediate representation, cannot optimize nearly as well as the
big compilers so the generated executables can be a bit slower and/or
bigger (though sometimes they may be smaller), however besides its
internal simplicity there are many advantages, mainly e.g. fast
compilation (claims to be 9 times faster than gcc) and small tcc
executable (about 100 kB). Seems to only support x86 at the moment.
* [88]scc: Another small/suckless C compiler, currently about 30 KLOC.
* [89]chibicc: Hell of a small C compiler (looks like around 10 KLOC).
* [90]DuskCC: [91]Dusk OS C compiler written in [92]Forth, focused on
extreme simplicity, probably won't adhere to standards completely.
* [93]8c, [94]8cc: Another small compiler.
* [95]c2bf: Partially implemented C to [96]brainfuck compiler.
* [97]lcc: Proprietary, source available small C compiler, about 20
KLOC.
* [98]pcc: A very early C compiler that was later developed further to
support even the C99 standard.
* Borland Turbo C: old proprietary compiler with [99]IDE.
* [100]sdcc (small device C compiler): For small 8 bit
[101]microcontrollers.
* msvc ([102]Micro$oft visual C++): Badly bloated proprietary C/C++
compiler by a shitty [103]corporation. Avoid.
* [104]M2-Planet: Simple compiler of C subset used for bootstrapping the
[105]GNU operating system.
* ...
Standard Library
Besides the pure C language the C standard specifies a set of
[106]libraries that have to come with a standard-compliant C
implementation -- so called standard library. This includes e.g. the stdio
library for performing standard [107]input/output (reading/writing to/from
screen/files) or the math library for mathematical functions. It is
usually relatively okay to use these libraries as they are required by the
standard to exist so the [108]dependency they create is not as dangerous,
however many C implementations aren't completely compliant with the
standard and may come without the standard library. Also many stdlib
implementations suck or you just can't be sure what the implementation
will prefer (size? speed?) etc. So for sake of [109]portability it is best
if you can avoid using standard library.
The standard library (libc) is a subject of live debate because while its
interface and behavior are given by the C standard, its implementation is
a matter of each compiler; since the standard library is so commonly used,
we should take great care in assuring it's extremely well written, however
we ALWAYS have to choose our priorities and make tradeoffs, there just
mathematically CANNOT be an ultimate implementation that will be all
extremely fast and extremely memory efficient and extremely portable and
extremely small. So choosing your C environment usually comprises of
choosing the C compiler and the stdlib implementation. As you probably
guessed, the popular implementations ([110]glibc et al) are [111]bloat and
also often just [112]shit. Better alternatives thankfully exist, such as:
* [113]musl
* [114]uclibc
* [115]not using the standard library :)
* ...
Good And Bad Things About C
Firstly let's sum up some of the reasons why C is so good:
* C as a language is relatively simple: Though strictly speaking it's
not in the league of most minimal languages like [116]Forth and
[117]Lisp, C is the next best thing in terms of [118]minimalism and
the small amount of bloat it contains is usually somehow justified at
least, the language (or its subset) can be implemented in a quite
minimal way if one so desires. It employs little [119]abstraction.
This all helps performance, freedom and encourages many
implementations. C's standard library also isn't gigantic, the
important parts basically just provide I/O and help with simple things
like manipulating strings and memory allocation, so new C
implementations aren't burdened by having to implement tons of
libraries.
* It is extremely fast and efficient: Owing to other mentioned points
such as good specification, simplicity, lack of bullshit and having a
good balance between low and high level attributes, C is known for
being possibly the fastest [120]portable language in existence, also
greatly efficient with memory etc.
* C doesn't limit you or hold (tie) your hands: This is bad for the
beginner but great for the expert, most of the times C won't "protect"
you from doing anything, even crashing your program -- this kind of
freedom is necessary to achieve truly marvelous things, C is like a
race car, it doesn't have speed limiters and automatic transmission,
nothing that would tie your hands or increase the car weight, it
trusts in you being a good driver.
* C is highly standardized: Many languages have some kind of "online
specification", however C is on the next level by literally being
officially standardized by the forefront standardizing organizations
like ANSI and ISO, by full time paid experts over many years and
iterations, so the language is extremely well defined and described,
down to saying which exact things are left undefined/unspecified,
leaving freedom of implementation that leads to the language's great
performance.
* It's extremely well establishes, optimized, stable and time tested,
with many tools: Being among the oldest languages, the language of the
old time [121]hackers and the language of [122]Unix, maybe the most
important piece of software in history, C has been so widely adopted,
reimplemented, optimized and tested over and over that it's considered
to be among the most essential pieces of software any platform has to
have. Everything on the low level is written in C, so you essentially
first have to have C to be able to run anything else. Many companies
have invested great many resources to making C fast as it benefited
them. While other languages come and go, or at least mutate and become
something else over time, C stands as one of very few stable things in
computer technology. There are also tons and tons of tools that help
with C development, various static analyzers, debuggers, code
beautifiers etcetc.
* It doesn't have any [123]modern [124]bullshit: There is no [125]OOP,
[126]generics, [127]garbage collection, no [128]package manager etc.
* There is a huge number of [129]compilers: While a "[130]modern"
language has some kind of main reference implementation and then maybe
one of two alternative implementations, C has dozens (maybe even
hundreds) of compilers. You'll find compilers under all the
[131]licenses, huge ones with many features and great optimizations,
small ones that will run on tiny devices, ones that compile very fast,
ones that translate C to other languages etcetc.
* It is elitist: The relatively higher difficulty of learning the
language has a nice effect of keeping idiots out of its community,
keeping the language less intoxicated by retarded ideas. { NOTE: The
word "elitist" here is not to really mean inherently "discriminating"
of course, but rather "unpopular" because it's quite different from
the mainstream and requires some effort on unlearning bad mainstream
habits, i.e. nowadays it needs some dedication, you can't just join in
effortlessly. It's elitist in the same way in which Unix systems or
suckless software are elitist. ~drummyfish }
* C is close to the [132]hardware, reflecting how computers work: This
has many advantages: firstly efficiency, as code that maps well to
hardware is predictable and efficient, lacking [133]magic in
translation. It simplifies implementations, making the language more
free. Then also the programmer himself is close to the machine, he has
to learn how it works, what it likes and dislikes -- a knowledge every
programmer has to have.
* There is a great balance between low and high level (minimalism vs
"features"): C seems to have hit a sweet spot at which it offers just
enough high level features for comfortable programming, such as
[134]data types, functions and expressions, while not crossing the
line beyond which it would have to pay a high cost for this comfort,
i.e. it managed to buy us a lot practically for free. Things like this
cannot really be planned well, it takes a genius and intuition to
design a language this way, this shows the greatness of the old master
programmers.
* It is [135]old, written only by white male [136]hackers, at times when
[137]capitalism was weaker: No [138]women were probably involved in
the development (of course we aren't racists or sexists, it's just a
fact that white men are best at programming), the development was
largely part of genuine research, at the time when computers weren't
mainstream and computer technology wasn't being raped as hard as
today. C developers didn't even think of embedding any political
message in the language. Times like this will never be repeated.
* ...
Now let's admit that nothing is [139]perfect, not even C; it was one of
the first relatively higher level languages and even though it has showed
to have been designed extremely well, some things didn't age great, or
were simply bad from the start. We still prefer this language as usually
the best choice, but it's good to be aware of its downsides or smaller
issues, if only for the sake of one day designing a better language.
Please bear in mind all here are just suggestions, they made of course be
a subject to counter arguments and further discussion. Here are some of
the bad things about the language:
* C specification (the ISO standard) is [140]proprietary :( The language
itself probably can't be copyrighted, nevertheless this may change in
the future, and a proprietary specs lowers C's accessibility and
moddability (you can't make derivative versions of the spec).
* The specification is also long as fuck (approx. 500 pages, our of that
163 of the pure language), indicating [141]bloat/complexity/obscurity.
A good, free language should have a simple definition. It could be
simplified a lot by simplifying the language itself as well as
dropping some truly legacy considerations (like [142]BCD systems?) and
removing a lot of undefined behavior.
* Some behavior is weird and has unnecessary exceptions, for example a
function can return anything, including a struct, except for an array.
This makes it awkward to e.g. implement vectors which would best be
made as arrays but you want functions to return them, so you may do
hacks like wrapping them inside a struct just for this.
* Some things could be made simpler, e.g. using [143]reverse polish
notation for expressions, rather than expressions with brackets and
operator precedence, would make implementations much simpler,
increasing sucklessness (of course readability is an argument).
* Some things could be dropped entirely ([144]enums, [145]bitfields,
possibly also unions etc.), they can be done and imitated in other
ways without much hassle.
* The preprocessor isn't exactly elegant, it has completely different
syntax and rules from the main language, not very suckless -- ideally
preprocessor uses the same language as the base language.
* The syntax is sucky sometimes, e.g. case with variable inside it HAS
TO be enclosed in curly brackets but other ones don't, data type names
may consist of multiple tokens (long long int etc.), multiplication
uses the same symbol as pointer dereference (*), many preprocessor
commands need to be on separate lines (makes some one liners
impossible), also it's pretty weird that the condition after if has to
be in brackets etc., it could all be designed better. Keywords also
might be better being single chars, like ? instead of if etc. (see
[146]comun). A shorter source code that doesn't try to imitate English
would be probably better.
* Some undefined/unspecified behavior is probably unnecessary --
undefined behavior isn't bad in general of course, it is what allows C
to be so fast and efficient in the first place, but some of it has
shown to be rather cumbersome; for example the unspecified
representation of integers, their binary size and behavior of floats
leads to a lot of trouble (unknown upper bounds, sizes, dangerous and
unpredictable behavior of many operators, difficult testing etc.)
while practically all computers have settled on using 8 bit bytes,
[147]two's complement and IEEE754 for [148]floats -- this could easily
be made a mandatory assumption which would simplify great many things
without doing basically any harm. New versions of C actually already
settle on two's complement. This doesn't mean C should be shaped to
reflect the degenerate "[149]modern" trends in programming though!
* Some basic things that are part of libraries or extensions, like fixed
width types and binary literals and possibly very basic I/O
(putchar/readchar), could be part of the language itself rather than
provided by libraries.
* All that stuff with .c and .h files is unnecessary, there should just
be one file type probably.
* ...
Basics
This is a quick overview, for a more in depth tutorial see [150]C
tutorial.
A simple program in C that writes "welcome to C" looks like this:
#include <stdio.h> // standard I/O library
int main(void)
{
// this is the main program
puts("welcome to C");
return 0; // end with success
}
You can simply paste this code into a file which you name e.g. program.c,
then you can compile the program from command line like this:
gcc -o program program.c
Then if you run the program from command line (./program on Unix like
systems) you should see the message.
Cheatsheet/Overview
Here is a quick reference cheatsheet of some of the important things in C,
also a possible overview of the language.
data types (just some):
data type values (size) printf notes
int (signed int, integer, at least -32767 to native integer,
...) 32767 (16 bit), often more %d fast (prefer for
speed)
integer, non-negative, at same as int but
unsigned int least 0 to 65535, often more %u no negative
values
signed char integer, at least -127 to %c, %hhi char forced to be
127, mostly -128 to 127 signed
unsigned char integer, at least 0 to 255 %c, %hhu smallest memory
(almost always the case) chunk, [151]byte
signed or
char integer, at least 256 values %c unsigned, used
for string
characters
integer, at least -32767 to like int but
short 32767 (16 bit) %hd supposed to be
smaller
unsigned short integer, non-negative, at %hu like short but
least 0 to 65535 unsigned
integer, at least for big signed
long -2147483647 to 2147483647 %ld values
(32 bit)
unsigned long integer, at least 0 to %lu for big unsigned
4294967295 (32 bit) values
long long integer, at least some -9 * %lld for very big
10^18 to 9 * 10^18 (64 bit) signed values
unsigned long integer, at least 0 to for very big
long 18446744073709551615 (64 %llu unsigned values
bit)
[152]float,
float floating point, some -3 * %f tricky, bloat,
10^38 to 3 * 10^38 can be slow,
avoid
double floating point, some -1 * %lf like float but
10^308 to 10^308 bigger
T [N] array of N values of type T array, if T is
char then string
pointer to type
T * memory address %p T, (if char then
string)
exact width,
uint8_t 0 to 255 (8 bit) PRIu8 two's compl.,
must include
<stdint.h>
int8_t -128 to 127 (8 bit) PRId8 like uint8_t but
signed
uint16_t 0 to 65535 (16 bit) PRIu16 like uint8_t but
16 bit
int16_t -32768 to 32767 (16 bit) PRId16 like uint16_t but
signed
uint32_t -2147483648 to 2147483647 PRIu32 like uint8_t but
(32 bit) 32 bit
int32_t 0 to 4294967295 (32 bit) PRId32 like uint32_t but
signed
signed integer
int_least8_t at least -128 to 127 PRIdLEAST8 with at least 8
bits, <stdint.h>
fast signed int.
int_fast8_t at least -128 to 127 PRIdFAST8 with at least 8
bits, <stdint.h>
struct structured data
type
There is no bool (true, false), use any integer type, 0 is false,
everything else is true (there may be some bool type in the stdlib, don't
use that). A string is just array of chars, it has to end with value 0
(NOT ASCII character for "0" but literally integer value 0)!
main program structure:
#include <stdio.h>
int main(void)
{
// code here
return 0;
}
branching aka if-then-else:
if (CONDITION)
{
// do something here
}
else // optional
{
// do something else here
}
for loop (repeat given number of times):
for (int i = 0; i < MAX; ++i)
{
// do something here, you can use i
}
while loop (repeat while CONDITION holds):
while (CONDITION)
{
// do something here
}
do while loop (same as while but CONDITION at the end), not used that
much:
do
{
// do something here
} while (CONDITION);
function definition:
RETURN_TYPE myFunction (TYPE1 param1, TYPE2 param2, ...)
{ // return type can be void
// do something here
}
compilation (you can replace gcc with another compiler):
* quickly compile and run: gcc myprogram.c && ./a.out.
* compile more properly: gcc -std=c99 -Wall -Wextra -pedantic -O3 -o
myprogram myprogram.c.
To [153]link a library use -llibrary, e.g. -lm (when using <math.h>),
-lSDL2 etc.
The following are some symbols ([154]functions, [155]macros, ...) from the
standard library:
symbol library description example
Writes a
putchar(c) stdio.h single putchar('a');
character to
output.
Reads a single
getchar() stdio.h character from int inputChar = getchar();
input.
Writes string
puts(s) stdio.h to output puts("hello");
(adds newline
at the end).
Complex print
func., allow
printf(s, a, b, ...) stdio.h printing printf("value is %d\n",var);
numbers, their
formatting
etc.
Complex
scanf(s, a, b, ...) stdio.h reading func., scanf("%d",&var);
allows reading
numbers etc.
Opens file
with given
fopen(f,mode) stdio.h name in FILE *myFile = fopen("myfile.txt","r");
specific mode,
returns
pointer.
Closes
fclose(f) stdio.h previously fclose(myFile);
opened file.
Writes a
fputc(c,f) stdio.h single fputc('a',myFile);
character to
file.
Reads a single
fgetc(f) stdio.h character from int fileChar = fgetc(myFile);
file.
Writes string
to file
fputs(s,f) stdio.h (without fputs("hello",myFile);
newline at
end).
Like printf
fprintf(s, a, b, ...) stdio.h but outputs to fprintf(myFile,"value is %d\n",var);
a file.
fscanf(f, s, a, b, Like scanf but
...) stdio.h reads from a fscanf(myFile,"%d",&var);
file.
Reads n elems
to data from
fread(data,size,n,f) stdio.h file, returns fread(myArray,sizeof(item),1,myFile);
no. of elems
read.
Writes n elems
from data to
fwrite(data,size,n,f) stdio.h file, returns fwrite(myArray,sizeof(item),1,myFile);
no. of elems
writ.
EOF stdio.h [156]End of int c = getchar(); if (c == EOF) break;
file value.
Returns
rand() stdlib.h pseudorandom char randomLetter = 'a' + rand() % 26;
number.
Seeds
srand(n) stdlib.h pseudorandom srand(time(NULL));
number
generator.
Value assigned
NULL stdlib.h, to pointers int *myPointer = NULL;
... that point
"nowhere".
Dynamically
allocates
malloc(size) stdlib.h memory, int *myArr = malloc(sizeof(int) * 10);
returns
pointer to it
(or NULL).
Resizes
dynamically
allocates
realloc(mem,size) stdlib.h memory, myArr = realloc(myArr,sizeof(int) * 20);
returns
pointer (or
NULL).
Frees
free(mem) stdlib.h dynamically free(myArr);
allocated
memory.
Converts
atof(str) stdlib.h string to double val = atof(answerStr);
floating point
number.
Converts
atoi(str) stdlib.h string to int val = atof(answerStr);
integer
number.
Value the
program should
EXIT_SUCCESS stdlib.h return on return EXIT_SUCCESS;
successful
exit.
Value the
EXIT_FAILURE stdlib.h program should return EXIT_FAILURE;
return on exit
with error.
Returns
sin(x) math.h [157]sine of float angleSin = sin(angle);
angle in
[158]RADIANS.
Like sin but
cos(x) math.h returns float angleCos = cos(angle);
cosine.
Returns
tan(x) math.h [159]tangent float angleTan = tan(angle);
of angle in
RADIANS.
Returns arcus
asin(x) math.h sine of angle, float angle = asin(angleSine);
in RADIANS.
Rounds a
ceil(x) math.h floating point double x = ceil(y);
value up.
Rounds a
floor(x) math.h floating point double x = floor(y);
value down.
Returns
fmod(a,b) math.h floating point double rem = modf(x,3.5);
reminded after
division.
Checks if
isnan(x) math.h given float if (!isnan(x))
value is NaN.
Float quiet
[160]NaN (not
NAN math.h a number) if (y == 0) return NAN;
value, don't
compare!
Computes
log(x) math.h natural double x = log(y);
[161]logarithm
(base [162]e).
Computes
log10(x) math.h decadic double x = log10(y);
[163]logarithm
(base 10).
Computes
log2(x) math.h binary double x = log2(y);
[164]logarithm
(base 2).
Computes
exp(x) math.h exponential double x = exp(y);
function
(e^x).
Computes
sqrt(x) math.h floating point double dist = sqrt(dx * dx + dy * dy);
[165]square
root.
Power, raises
pow(a,b) math.h a to b (both double cubeRoot = pow(var,1.0/3.0);
floating
point).
Computes
abs(x) math.h [166]absolute double varAbs = abs(var);
value.
Maximum value
INT_MAX limits.h that can be printf("int max: %d\n",INT_MAX);
stored in int
type.
Fills block of
memset(mem,val,size) string.h memory with memset(myArr,0,sizeof(myArr));
given values.
Copies bytes
of memory from
memcpy(dest,src,size) string.h one place to memcpy(destArr,srcArr,sizeof(srcArr);
another,
returns dest.
Copies string
strcpy(dest,src) string.h (zero char myStr[16]; strcpy(myStr,"hello");
terminated) to
dest, unsafe.
Like strcpy
but limits max
strncpy(dest,src,n) string.h number of strncpy(destStr,srcStr,sizeof(destStr));
bytes to copy,
safer.
Compares two
strcmp(s1,s2) string.h strings, if (!strcmp(str1,"something"))
returns 0 if
equal.
Returns length
strlen(str) string.h of given int l = strlen(myStr);
string.
Finds
substring in
strstr(str,substr) string.h string, if (strstr(cmdStr,"quit") != NULL)
returns
pointer to it
(or NULL).
Stores
calendar time
time(t) time.h (often Unix printf("tstamp: %d\n",(int) time(NULL));
t.) in t (can
be NULL),
returns it.
Returns
approx. CPU
clock() time.h cycle count printf("CPU ticks: %d\n",(int) clock());
since program
start.
Number of CPU
CLOCKS_PER_SEC time.h ticks per int sElapsed = clock() / CLOCKS_PER_SEC;
second.
Some Programs In C
TODO
See Also
* [167]B
* [168]D
* [169]comun
* [170]C tutorial
* [171]C pitfalls
* [172]C programming style
* [173]C++
* [174]IOCCC
* [175]HolyC
* [176]QuakeC
* [177]Pascal
* [178]Fortran
* [179]LISP
* [180]FORTH
* [181]memory management in C
Links:
1. c_tutorial.md
2. old.md
3. low_level.md
4. static_typing.md
5. imperative.md
6. programming_language.md
7. lrs.md
8. bloat.md
9. modern.md
10. kiss.md
11. suckless.md
12. linux.md
13. openbsd.md
14. c.md
15. java.md
16. javascript.md
17. comun.md
18. computer.md
19. modern.md
20. oop.md
21. pseudocode.md
22. english.md
23. preprocessor.md
24. macro.md
25. portability.md
26. pointer.md
27. memory_leak.md
28. undefined_behavior.md
29. bug.md
30. jokes.md
31. modern.md
32. io.md
33. file.md
34. sdl.md
35. posix.md
36. portability.md
37. assembly.md
38. pointer.md
39. driver.md
40. operating_system.md
41. driver.md
42. game.md
43. machine_learning.md
44. python.md
45. c.md
46. lrs.md
47. assembly.md
48. python.md
49. js.md
50. oop.md
51. fun.md
52. compiler_bomb.md
53. bell_labs.md
54. unix.md
55. dennis_ritchie.md
56. brian_kerninghan.md
57. b.md
58. portability.md
59. recursion.md
60. ken_thompson.md
61. algol.md
62. scope.md
63. hacking.md
64. rms.md
65. gcc.md
66. gnu.md
67. ansi_c.md
68. lrs.md
69. modern.md
70. lrs.md
71. stdint.md
72. float.md
73. array.md
74. macro.md
75. bloat.md
76. lrs.md
77. bloat.md
78. future_proof.md
79. oop.md
80. gcc.md
81. bloat.md
82. optimization.md
83. intermediate_representation.md
84. clang.md
85. llvm.md
86. tcc.md
87. suckless.md
88. scc.md
89. chibicc.md
90. duskcc.md
91. duskos.md
92. forth.md
93. 8c.md
94. 8cc.md
95. c2bf.md
96. brainfuck.md
97. lcc.md
98. pcc.md
99. ide.md
100. sdcc.md
101. mcu.md
102. microsoft.md
103. corporation.md
104. m2_planet.md
105. gnu.md
106. library.md
107. io.md
108. dependency.md
109. portability.md
110. glibc.md
111. bloat.md
112. shit.md
113. musl.md
114. uclibc.md
115. dependency.md
116. forth.md
117. lisp.md
118. minimalism.md
119. abstraction.md
120. portability.md
121. hacking.md
122. unix.md
123. modern.md
124. bullshit.md
125. oop.md
126. generics.md
127. garbage_collection.md
128. package_manager.md
129. compiler.md
130. modern.md
131. license.md
132. hw.md
133. magic.md
134. data_type.md
135. old.md
136. hacking.md
137. capitalism.md
138. woman.md
139. perfect.md
140. proprietary.md
141. bloat.md
142. bcd.md
143. reverse_polish.md
144. enum.md
145. bitfield.md
146. comun.md
147. twos_complement.md
148. float.md
149. modern.md
150. c_tutorial.md
151. byte.md
152. float.md
153. linking.md
154. function.md
155. macro.md
156. eof.md
157. sin.md
158. rad.md
159. tan.md
160. nan.md
161. log.md
162. e.md
163. log.md
164. log.md
165. sqrt.md
166. abs.md
167. b.md
168. d.md
169. comun.md
170. c_tutorial.md
171. c_pitfalls.md
172. programming_style.md
173. cpp.md
174. ioccc.md
175. holyc.md
176. quakec.md
177. pascal.md
178. fortran.md
179. lisp.md
180. forth.md
181. memory_management.md