drummyfish/less_retarded_wiki
5
2
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Im coooooooooooooommmitting

Browse source
This commit is contained in:
Miloslav Ciz 2022-02-09 18:04:10 +01:00
parent 216d43f700
commit 2a766cfdb1
2 changed files with 17 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
c_pitfalls.md
View file

@ -1,16 +1,18 @@
# C Pitfalls
[C](c.md) is a powerful language that offers almost absolute control and maximum performance which necessarily comes with responsibility and danger of shooting yourself in the foot. Without knowledge of the pitfalls you may well find yourself fallen into one of them.
[C](c.md) is a powerful language that offers almost absolute control and maximum performance which necessarily comes with responsibility and danger of shooting oneself in the foot. Without knowledge of the pitfalls you may well find yourself fallen into one of them.
Unless specified otherwise, this article supposes the C99 standard of the C language.
## Undefined/Unspecified Behavior
Undefined, unspecified and implementation-defined behaviors are kinds of unpredictable and sometimes non-intuitive behavior of certain operations that may differ between compilers, platforms or runs because they are not defined by the language specification; this is mostly done on purpose as to allow some implementation freedom which allows implementing the language in a way that is most efficient on given platform. This behavior may be completely random (unpredictable) or implementation-specified (consistent within each implementation but potentially different for each of them). In any case, one has to avoid any such unpredictable behavior in basically any sane program. Note that tools such as [cppcheck](cppcheck.md) can help find undefined behavior in code. Description of some of these behaviors follow.
Undefined, unspecified and implementation-defined behaviors are kinds of unpredictable and sometimes non-intuitive behavior of certain operations that may differ between compilers, platforms or runs because they are not defined by the language specification; this is mostly done on purpose as to allow some implementation freedom which allows implementing the language in a way that is most efficient on given platform. This behavior may be completely random (unpredictable) or implementation-specified (consistent within each implementation but potentially different between implementations). In any case, one has to be very careful about letting such behavior influence computations. Note that tools such as [cppcheck](cppcheck.md) can help find undefined behavior in code. Description of some of these behaviors follow.
**Data type sizes including int and char may not be the same on each platform**. Even though we almost take it for granted than char is 8 bits wide, in theory it can be wider. The int (and unsigned int) type width should reflect the architectures native integer type, so nowadays mostly it's mostly 32 or 64 bits. To deal with this we can use the standard library `limits.h` and `stdint.h` headers.
**Order of evaluation of operands/arguments is not specified**. I.e. in an expression or function call it is not defined which operands or arguments will be evaluated first, the order may be completely random and the order may differ even when evaluating the same expression at another time. This is demonstrated by the following code:
**No specific [endianness](endian.md) is enforced**. Nowadays little endian is what you'll encounter on most platforms, but e.g. [PowerPC](ppc.md) uses big endian.
**Order of evaluation of operands and function arguments is not specified**. I.e. in an expression or function call it is not defined which operands or arguments will be evaluated first, the order may be completely random and the order may differ even when evaluating the same expression at another time. This is demonstrated by the following code:
```
#include <stdio.h>
@ -34,10 +36,16 @@ int main(void)
**Bit shifts by type width or more are undefined.** Also bit shifts by negative values are undefined. So e.g. `x >> 8` is undefined if width of the data type of `x` is 8 bits.
**Overflow behavior of signed addition is not guaranteed.** Sometimes we suppose that addition of two signed integers that are past the data type's limit will produce two's complement overflow, but in fact this operation's behavior is undefined.
## Memory Unsafety
Besides being extra careful of writing safe memory code, one needs to also know that **some functions of the standard library are memory unsafe**. This is regarding mainly string functions such as `strcpy` or `strlen` which do not check the string boundaries (i.e. they rely on not being passed a string that's not zero terminated and so can potentially touch memory anywhere beyond); safer alternatives are available, they have an `n` added in the name (`strncpy`, `strnlen`, ...) and allow specifying a length limit.
Besides being extra careful about writing memory safe code, one needs to also know that **some functions of the standard library are memory unsafe**. This is regarding mainly string functions such as `strcpy` or `strlen` which do not check the string boundaries (i.e. they rely on not being passed a string that's not zero terminated and so can potentially touch memory anywhere beyond); safer alternatives are available, they have an `n` added in the name (`strncpy`, `strnlen`, ...) and allow specifying a length limit.
## Different Behavior in C vs C++
## Different Behavior between C and C++
TODO
C is **not** a subset of C++, i.e. not every C program is a C++ program (for simple example imagine a C program in which we use the word `class` as an identifier). Furthermore a C program that is at the same time also a C++ program may behave differently when compiled as C vs C++. Of course, all of this may also apply between different standards of C, not just between C and C++.
For portability sake it is good to try to write C code that will also compile as C++ (and behave the same). For this we should know some basic differences in behavior between C and C++.
TODO: specific examples

4
www.md
View file

@ -1,6 +1,8 @@
# World Wide Web
World Wide Web (www or just *the web*) is (or was, if we accept that by 2021 the web is basically dead) a network of interconnected documents on the [Internet](internet.md) (called *websites* or *webpages*). Some people confuse the web with the Internet, but of course those people are retarded: web is just one of many service existing on the Internet (other ones being e.g. [email](email.md) or [torrents](torrent.md)). In order to browse the web you need an Internet connection and a [web browser](browser.md).
World Wide Web (www or just *the web*) is (or was, if we accept that by 2021 the web is basically dead) a network of interconnected documents on the [Internet](internet.md) (called *websites* or *webpages*). Webpages are normally written in [HTML](html.md) language and can refer to each other by [hyperlinks](hyperlink.md). The web itself works on top of the [HTTP](http.md) protocol. Some people confuse the web with the Internet, but of course those people are retarded: web is just one of many service existing on the Internet (other ones being e.g. [email](email.md) or [torrents](torrent.md)). In order to browse the web you need an Internet connection and a [web browser](browser.md).
Web is kind of a bloated [shit](shit.md), for more [suckless](suckless.md) alternatives see [gopher](gopher.md) and [gemini](gemini.md).
The web is perhaps the best, saddest and funniest example of [capitalist](capitalist_software.md) [bloat](bloat.md), the situation with web sites is completely ridiculous and depressive. A nice article about the issue, called *The Website Obesity Crisis*, can be found at https://idlewords.com/talks/website_obesity.htm. There is also a tool for measuring a website bloat at https://www.webbloatscore.com/: it computes the ratio of the page size to the size of its screenshot (e.g. [YouTube](youtube.md) currently scores 35.7).