Resources that have influenced me as a C programmer

From http://www.reddit.com/r/C_Programming/comments/249cmt/resources_that_have_influenced_me_as_a_c/

http://stackoverflow.com/questions/tagged/c

The GNU C Library Reference. Also commonly available as 'info libc'. It should be read like a book. Really.

The Kernel CodingStyle, has some pretty good advice.

What every programmer should know about memory is very relevant for high-speed processing. This is the LWN article.

Kernel design patterns. Another great LWN link. I always smile a little whenever I use the container_of() macro.

Recursive Make Considered Harmful. Makes a fine beverage when mixed with Autotools.

Gnulib - the GNU Portability Library. Add in small quantities.

GNU C Language Extensions. I try to stay pretty compiler-agnostic, but there are some nifty things here. I would have never known about zero-length arrays if not for this.

Linux Device Drivers, 3rd edition.. Definitely worth reading.

The Linux Programming Interface. Likewise.

K&R Second Edition. Almost forgot this one!

GNU Screen. Nothing specific to C programming, but this utility deserves mention.

More than anything, man pages, 'info libc', reading header files, etc. Ways to look things up without first turning to Google, which often links to low signal-to-noise resources.

click is a Python package for creating beautiful command line interfaces

click is a Python package for creating beautiful command line interfaces in a composable way with as little amount of code as necessary. It’s the “Command Line Interface Creation Kit”.

import click

@click.command()
@click.option('--count', default=1, help='number of greetings')
@click.option('--name', prompt='Your name',
              help='the person to greet', required=True)
def hello(count, name):
    for x in range(count):
        print('Hello %s!' % name)

if __name__ == '__main__':
    hello()

python click_test.py --help
Usage: click_test.py [OPTIONS] NAME

Options:
  --count=COUNT  number of greetings
  --help         Show this message and exit.

The Linux Graphics Stack

The Direct Rendering Manager (DRM) is a device-independent kernel-level device driver that provides support for the Direct Rendering Infrastructure.

Direct Rendering Infrastructure (DRI) is an interface and a free software implementation inside the kernel used by the X Window System/Wayland to securely allow user applications to access the video hardware without requiring data to be passed through the display server. Its primary application is to provide hardware acceleration for the Mesa implementation of OpenGL, which is the core of the DRI OpenGL drivers. Without DRI, programs have to use the CPU while rendering (indirect rendering), which degrades overall performance. DRI has also been adapted to provide OpenGL acceleration on a framebuffer console without a display server running.

Mode setting (KMS) is a software operation that activates a display mode (screen resolution, color depth, and refresh rate) for a computer's display adapter.

Wayland is a protocol that specifies the communication between the display server (called Wayland compositor) and its clients. It was initially designed as a replacement for the X Window System. In stark contrast to the latter, Wayland clients will render without detour directly into their own buffer located in the graphics memory, through the use of EGL with some additional Wayland-specific extensions to EGL.
The display manager is to do the compositing, hence it will incorporate a big chunk of the functionality of current-day compositing window managers. It will composite those buffers to form the on-screen display of application windows. The Wayland protocol is essentially only about input handling and buffer management. The handling of the input hardware relies on evdev in Linux, and similar components in other operating systems.

EGL is an interface between Khronos rendering APIs (such as OpenGL, OpenGL ES or OpenVG) and the underlying native platform windowing system. EGL handles graphics context management, surface/buffer binding, rendering synchronization, and enables "high-performance, accelerated, mixed-mode 2D and 3D rendering using other Khronos APIs." EGL is managed by the non-profit technology consortium Khronos Group.

evdev (for event device) is a component of the Linux kernel for handling input (from keyboards, mice, joysticks, etc.) and a closely related input driver for both the X.Org Server and Wayland compositors. The kernel component is glue code which translates input events from peripheral-specific drivers into a generic structure which the input driver can easily translate into X11 events. Thus every input device with a Linux driver is compatible with the X.Org input driver, making X.Org much easier to configure.

Mesa is a collection of free and open-source libraries that implement OpenGL and several other APIs related to hardware-accelerated 3D rendering, 3D computer graphics and GPGPU.

Elbrus-4S

Russia is ready to produce new processor Elbrus-4S based on own microprocessors architecture with operations dependency analysis and order optimization via compiler. Also they have Linux based OS with modified 2.6.33 kernel that supports hard real-time scheduling

News

MCST News

Architecture (ru)
Elbrus OS (ru)

Full stack developer

Full-stack разработчики
The Full Stack Part I 
What is a Full Stack developer?

Shared libraries and dynamic linker

cc -g -c prog.c mod1.c mod2.c mod3.c
cc -g -o prog_nolib prog.o mod1.o mod2.o mod3.o

strip(1) - discard symbols from object files.

Static lib:

ar r libdemo.a mod1.o mod2.o mod3.o

ar tv libdemo.a
# rw-rw-r-- 1000/1000 1003352 Apr 14 11:24 2014 mod1.o
# rw-rw-r-- 1000/1000 403352 Apr 14 11:24 2014 mod2.o
# rw-rw-r-- 1000/1000  43352 Apr 14 11:24 2014 mod3.o

cc -g -o prog prog.o libdemo.a
# or
cc -g -o prog prog.o -Lmylibdir -ldemo

./prog

Dinamic lib:

gcc -g -c -fPIC -Wall mod1.c mod2.c mod3.c
gcc -g -shared -o libfoo.so mod1.o mod2.o mod3.o
# or 
gcc -g -fPIC -Wall mod1.c mod2.c mod3.c -shared -o libfoo.so

gcc -g -Wall -o prog prog.c libfoo.so
LD_LIBRARY_PATH=. ./prog

nm(1) - list symbols from object files
readelf(1) - displays information about ELF files
objdump(1) - display information from object files
ldd(1) - print shared library dependencies
ldconfig(1) - configure dynamic linker run-time bindings

nm mod1.o
readelf -s mod1.o

objdump --all-headers libfoo.so
readelf -d libfoo.so

Process shared libs:

cat /proc/PID/maps

Shared libs that prog required:

ldd /usr/sbin/tcpdump
# linux-vdso.so.1 =>  (0x00007fffe17ff000)
# libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff285828000)
# libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007ff2855ed000)
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff285224000)
# libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff285020000)
# libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff284e07000)
# /lib64/ld-linux-x86-64.so.2 (0x00007ff28606f000)

Where function defined:

nm -A /usr/lib/lib*.so 2> /dev/null | grep ' crypt$'

All system shared libs:

ldconfig –p
#1768 libs found in cache `/etc/ld.so.cache'
# libzvbi.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi.so.0
# libzvbi-chains.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0
# libzltext.so.0.13 (libc6,x86-64) => /usr/lib/libzltext.so.0.13
# libzlcore.so.0.13 (libc6,x86-64) => /usr/lib/libzlcore.so.0.13
# libzip.so.2 (libc6,x86-64) => /usr/lib/libzip.so.2
#...

Path: LD_LIBRARY_PATH, DT_RPATH, DT_RUNPATH, $ORIGIN

gcc -Wl,-rpath,'$ORIGIN'/lib ...

Run-time symbol resolution:

gcc -g -c -fPIC -Wall -c foo.c
gcc -g -shared -o libfoo.so foo.o
gcc -g -o prog prog.c libfoo.so
LD_LIBRARY_PATH=. ./prog
# main-xyz

Monitoring dynamic linker:

LD_DEBUG=help ./prog
LD_DEBUG=all ./prog

Two types of people