C Help and Discussion

The C Programming Logo

The Better Logo

/g/ Programming Challenges

The Boys

The Bible

/chad/

C Help and Discussion - or /chad/, is a ongoing general where people discuss all things C.

Show and talk about what your currently working on, or things you've worked on in the past.

Join our IRC channel: #/g/chad at irc.rizon.net

The past threads are enumerated here.

Template

Let's have a C thread. Post what you're working on! Show what you're interested in!

Last thread(s): >>OLD...

Wiki: https://wiki.installgentoo.com/wiki//chad/

IRC: #/g/chad at irc.rizon.net / irc://irc.rizon.net:+6697/%2Fg%2Fchad
Matrix: https://matrix.to/#/#chad:data.haus
Telegram: https://t.me/+itOpQDA2Nbk3ZDZh 

Don't know how to write C? Start here:
K&R PDF: https://files.catbox.moe/80f07b.pdf
KING PDF: https://files.catbox.moe/a875c2.pdf
Modern C: https://files.catbox.moe/xeb93p.pdf

Standards:
C89: https://files.catbox.moe/rfqd57.pdf
C99: https://files.catbox.moe/hs2tqa.pdf

The old matrix.

Useful Links

Getting started

• Hello World!
• C Programming FAQs: Frequently Asked Questions

Challenge

• DPT Roll

Books

• K&R C Second Edition
• King - C Programming - A Modern Approach
• C: A Reference Manual
• P.J. Plauger The Standard C Library
• bwk & rob - The Practice of Programming
• RMS Guide
• Beej's Guide to C Programming
• GCC PDF
• /g/entoomen book collection torrent
• /g/entoomen book collection direct download

Standards

• C89/C90 · C99 · C11 · C17 · C23

Articles

• Some Were Meant For C
• Untangling Lifetimes: The Arena Allocator
• Memory Allocation Strategies
• Modern C for C++ Peeps
• scanf guide

Tools

Building and Build systems

Small Scale

Makefile: It is best to use only for small and simple projects.

Ninja: Not for humans. Fast.

redo: One day... It'll be the best and the universal standard!

Scalable

CMake: CMake is a multi-platform build system that is a modern alternative to Autotools. See this /gedg/ CMake Guide.

Meson: _{CMake with better syntax.}

Autotools: GNU Autotools is a build system that generates Makefiles which comply to GNU Coding Standards, which makes it easier for users of your software to adjust the build process for their needs. The ability to do out-of-tree builds, cross-compilation and staged installs comes out of the box, so you don't have to implement it yourself.

Video guide by David A. Wheeler · Basic Template: >>92441749

Debugging

• Valgrind: Memory leak detector, cache checker, and some other tools.
• Splint
• gdb
• lldb

Compilers

• GCC: The GNU Compiler Collection (Originally known as the GNU C Compiler...)
• Clang/LLVM: An "LLVM native" C/C++/Objective-C compiler.
• MSVC: The Microsoft C/C++ Compiler. Don't know anything about it since using spyware is discouraged.
• ICC: The Intel C Compiler. Uses LLVM as its backend. Caution should be taken if used due to previous behavior by Intel (Maliciously generating slower code for non-Intel processors)
• TCC: The Tiny C Compiler, notable for its extremely fast compilation speeds.
• CompCert: A C99 compiler intended for the compilation of life-critical and mission-critical software and meeting high levels of assurance. Non-free.

Obscure Compilers

• Turbo C: A free C++ compiler from Borland. It comes with an IDE and debugger.
• Movfuscator: A single instruction (MOV) C89 compiler created for lulz by the reverse-engineering god Christopher Domas.

Recommended Build Options

Standards

-std= (valid: c89, c99 c11 c17, c2x) (additional: c90:c89, c18:c17)

Determine the language standard. See Language Standards Supported by GCC, for details of these standard versions. This option is currently only supported when compiling C or C++. -std=c99 is usually a good choice.

On MSVC use /D_CRT_SECURE_NO_WARNINGS to disable warnings regarding the so-called "secure" functions. These aren't widely supported outside of MSVC, and their benefits are questionable. See N1967 for more information.

-ansi: Common alias for -std=c89.

Warnings

GCC Warnings are listed here. For both GCC and Clang, it is generally recommended to use -Werror -Wall -Wextra -Wpedantic.

-Werror: Make all warnings into errors.

-Wall: Enables a large set of warnings, some of which may be undesirable. Very recommended to use.

-Wextra: This enables some extra warning flags that are not enabled by -Wall. Recommended to use.

-Wpedantic: Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard specified by any -std option used (Example: -std=c99).

-Wstrict-aliasing=3: Pointer aliasing is when two different pointers can point to the same memory location. Strict aliasing is a set of rules C compilers use to determine when this can happen and when it can't. 3 may be too high for beginners and can spit out some false-positives, 2 is typically a better choice.

-Wwrite-strings: Warns on write to string literals, which have the type of `char []` however, writing to a string literal is Undefined Behavior (UB), so it makes more sense to treat them as `const char []` (even DMR wanted to make string literals const: https://www.lysator.liu.se/c/dmr-on-noalias.html).

-Wvla: Warns if there is a variable length array used in the code. VLAs are either unnecessary because you know the upper bound and are able to do buf[UPPER_BOUND] or are a stack overflow waiting to happen. Some smaller compilers like cproc do not implement VLAs, possibly avoiding use of this option may aid portability.

-Wcast-align=strict: can warn on some newb casting.

-Wstrict-prototypes: Warns on function declarations that lack an explicit set of parameters like f(), which have a specialized purpose in C and only C, where the set arguments are set at the implementation site.

-Wstringop-overflow=4: Warns for calls to string manipulation functions such as memcpy or strcpy that are determined to overflow the destination buffer. At =4 it additionally warns about overflowing any data members, and when the destination is one of several objects it uses the size of the largest of them to decide whether to issue a warning.

-Wno-logical-op-parentheses: C has an order precedence of first && then ||. This is however warned against, and at a glance with this knowledge it is much easier to tell the difference between (a && b || c) and (a && (b || c)) than enforcing that warning like ((a && b) || c) and (a && (b || c)).

Optimizing & Release options

GCC optimization options can be seen here.

-O0: Reduce compilation time and make debugging produce the expected results. This is the default.

-O1: Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function. With -O, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time.

-O2: Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code.

-O3: Enables all optimizations specified by -O2 and some additional flags.

-Ofast: Disregard strict standards compliance. Enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math, -fallow-store-data-races and the Fortran-specific -fstack-arrays, unless -fmax-stack-var-size is specified, and -fno-protect-parens. It turns off -fsemantic-interposition.

-Os Optimize for size. Enables all -O2 optimizations except those that often increase code size. It also enables -finline-functions, causes the compiler to tune for code size rather than execution speed, and performs further optimizations designed to reduce code size. Generally not recommended due to its "hyper-focus" on minimizing the size of a program, even at the expense of obvious, highly beneficial optimizations.

-Og: Optimize debugging experience. Should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0. Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging.

-flto=N: LTO provides Link time optimization, try -flto=auto on release builds.

-fwhole-program: provides optimization by the knowledge of 'this is the whole program' whether or not that is true, in principle it provides no advantage. You cannot use it for compiling libraries because the symbols need to be externally visibly in those cases, but for making a binary all you should need exposed is _start and main, which this flag preserves.

-s and strip: strip is primarily useful for release builds, it strips unneeded symbols and can be invoked at link-time with -s or separately after the fact with strip PROGRAM

Debug options

Generally -Og -g, use -ggdb instead of -g if you intend to use GNU Debugger. -fsanitize=... has many useful features described in The GCC PDF, you however cannot combine some directives with any debugger.

Tools like Valgrind, Splint may also help you debug and improve your code.

Diagnostic options

Consider -fno-diagnostics-show-caret for GCC or -fno-caret-diagnostics for Clang to reduce the number of lines per actual error in the compiler output.

C Misconceptions

C is too small of a language to be useful!

While C is a relatively small language, it provides enough facilities to create anything you can imagine. It's no secret that most interpreted languages like Perl, Python, Lua, and countless Lisps/Schemes/Forths are implemented in C. Anything you can implement in the aforementioned languages, can also be implemented in C. This could be said about many small languages which aren't usable at all, but C provides enough tools of abstraction to be useful in projects of any scale, from /usr/bin/true to /boot/vmlinuz.

On the other hand, C's simplicity makes it much easier to learn the whole language. Anyone with previous programming experience can learn the entirety of C in just a few weeks. After learning the language itself, one spends the rest of their C programming career figuring out the best way to apply it. This is more productive, as you're gaining actual CS knowledge and not focusing on superficial things like a particular language's syntax/implementation details.

C has no package manager!

C has many, many package managers, one for every GNU/Linux Distribution. Language-specific package managers tend to be a bad idea anyway

C's lack of memory safety leads to buggy programs!

Good coding habits will prevent many such bugs. There are also tools like ASan and UBSan which help find memory bugs during testing.