Merge branch 'master' of https://bis64wqhh3louusbd45iyj76kmn4rzw5ysawyan5bkxwyzihj67c5lid.onion/anon/chad_standard

README.md

@@ -1,125 +1,22 @@
-# Chad Coding Standard
+# /chad/ - C Help And Discussion
+This repo attempts to collect and organize
+information related to the /chad/ general.
 
-The most important thing is to be consistent with an existing codebase, don't make unnecessary large changes.
-If there are places where brackets should be used, use them! except for only `else if`
+![media/chad.png](media/chad.png)
 
-### First Off ###
- + keep a line width of 80
- + string NULL termination is spelled '\0', not '\00'
- + use NULL not 0, when applicable
- + Use the correct editor
+## What is there to see here?
++ the [standard](standard.md) is a coding guideline created by the IRC group
++ [the thread copy pasta](chad.pasta)
++ [memes and such](media/)
++ [/chad/ history](https://igwiki.lyci.de/wiki/C_Help_and_Discussion)
++ [incomplete list of things Xolatile hates](miscellaneous/xolatile_hates.list)
++ [learning materials for people of varying expertise](resources/)
+  * [Some were meant for C](resources/some_were_meant_for_c.pdf)
 
-### Compilation ###
- + Provide Makefile
-
-	Preferably GNU Make, or POSIX Make
-
-### Headers ###
- + NEVER use relative paths, use well a written build script with `-I`, `-L` and other options
- + Use these kinds of header guards:
-```c
-	#ifndef NAME_H
-	...
-	#define NAME_H
-	#endif
-```
- + Headers should, if meant to be exposed externally in any way, should have namespacing prefixes
-
-### Naming ###
- + Namer (likely project owner) chooses standard spelling, try to stay to one locale when it comes to naming things (In US, color, In Europoor, caulouur [Sic])
- + snake\_case\_for\_all
-
-### Indentation
- + Tabs & Spaces (get Smart Tabs plz)
-
-### Macros ###
- + Parenthesize macro values
-
-### Padding ###
- + Pad after commas
- + Add padding around if, while, and for clauses
- + Do not pad after a function name `func()`, NEVER `func ()`
- + Do not pad inside parentheses `func(a)`, NEVER `func( a )`
- + Pad inside brackets always `{ ...; }`
-
-### Declaration ###
- + for functions always abide [static|extern] [inline] [type]
- + Put pointers in the center `char * abc`
- + Definitely put pointers together always, `char *** x` is definitely way better than `char * * * x` don't trust Anon or Xolatile on this matter and do not attempt to decide things democratically
- + Function parameters should remain on the same line... `func (int a) {...`
- + If a function has way too many parameters (line length greater than limit), format them into a block or lay them out in a indented list.
- + Align adjacent declarations horizontally
- + Always typedef structs and enums, avoid `struct mytype myvar;` if possible
- + You may use anonymous structures
-
-### Conditionals ###
-
-+ align like this:
-```c
-	if (!a
-	&&   b
-	&&  !c) {
-	...
-	}
-```
-+ avoid useless comparison information
-```c
-	if (a != 0) /* BAD */
-	if (a) /* as god intended */
-```
-
-### Switch ###
- + Multi-line
-```c
-	switch (...) {
-		case ...: {
-			...
-			break;
-		}
-	}
-```
- + Single line (if you dare)
-```c
-	switch (...) {
-		case ...:
-		{ ...; break; }
-	}
-```
-
-### Loops ###
- + Try to use the alphabetical iterators `i, j, k, ...`, try not to use more than three iterators
- + Use `while (1)` for infinite loops
-
-### Operators ###
- + Use prefix increment by default `++i`
- + Use spaces in-between operators on the same line ALWAYS! (note that multi-line operators should have tabs for normal indenting, but otherwise should use spaces)
-
-# Advice
-
-### Compilation ###
- + Resolve All Feasible Warnings given by selected compilers
-	`clang -Weverything`
-	`gcc -Wall -Wextra -Pedantic`
- + Consider tools like splint, but don't break your back over it
-
-### The Dreaded Multi-line Comment ###
- + Don't ever use them unless you have to
-
-	C++ comments for logical separation and small comments
-
-	C comments for large explanation
- + Use them always and vanish C++ demons from your code
- + Use `#if 0... #endif /* 0 */` if you want to comment out blocks of code
-
-### Indentation
- + Try not to go over 4 levels
-
-### Parenthesizing ###
- + Do not parenthesize return statements
-
-### Loops ###
- + If you will have NO other use for an iterator, put it inside the for loop declaration, C99> style
- + Avoid commas in conditionals, it'll make Xolatile seethe
-
-### Naming ###
- + Use the POSIX reserved \_t suffix for new types
+## See also
++ IRC - #/g/chad @ rizon.net *(bridged)*
++ Telegram - [https://t.me/HelpAndDiscussion](https://t.me/HelpAndDiscussion) *(bridged)*
++ XMPP - chad@conference.jabjab.de *(bridged)*
++ [Anon's gitea mirroring the software of multiple /chad/s](bis64wqhh3louusbd45iyj76kmn4rzw5ysawyan5bkxwyzihj67c5lid.onion)
++ [installgentoo wiki /chad/ page](https://wiki.installgentoo.com/wiki/C_Help_and_Discussion)
++ [wiki mirror](https://igwiki.lyci.de/wiki/C_Help_and_Discussion)

miscellaneous/chad_quotes.txt

@@ -51,3 +51,15 @@ xolatile | I mentioned that I used smartphone for 2 days...
 anon8697 | xolatile: how many packs smoked did that result in?
 xolatile | 70 cigs, lemme explain...
 anon8697 | KEK
+
+<ATelegramUser3> You are a sex haver and I am not, isn't that a violation of my freedoms ?
+
+<alifib> in the light of several people killing themselves here, i'd say we need LESS bridges!
+
+anon8697 | alifib: the main problem with your username is its lenght
+emilemil | it's not exactly 8 characters, you see
+  alifib | :(
+  alifib | alifibob?
+anon8697 | perfect
+  alifib | but my name is not bob :(
+

miscellaneous/daves_suicide_letter.txt

@@ -0,0 +1,18 @@
+2024-03-26 13:10:42	dave9001	Anyway, now that Emil is here, I can post what I've been meaning to.
+2024-03-26 13:12:40	dave9001	No computer program can be completely safe, we've gone over this before. Ultimately, there will always be unsafe code that you interface with, at some level. It's extremely sophistic, however, if not simply idiotic, to argue that since every language is unsafe on same level, every language is equally unsafe. Rust's ownership semantics provide compile-time safety guarantees that no other language does. 
+2024-03-26 13:12:46	dave9001	It is the only language of its kind to both be low-level, and entirely safe.
+2024-03-26 13:12:49	dave9001	That also is not to say that Rust's ownership model is free of abstraction leaks. Despite it having no runtime cost, it still is an abstraction. This repository implements, in safe Rust, segfaults and use-after-frees -> https://github.com/Speykious/cve-rs
+2024-03-26 13:12:53	dave9001	The way this is done is through a particular soundness hole in the implementation, allowing for lifetime expansion. Also, give the LICENSE file a read, it got a chuckle out of me. Good luck with that shit.
+2024-03-26 13:12:57	dave9001	...
+2024-03-26 13:12:59	dave9001	But that doesn't matter, does it? You probably already realize that your argument is flawed, and your own behavior (your usage of Ada) contradicts it.
+2024-03-26 13:13:02	dave9001	Programming languages are simply tools to be used, they're a means to the goal of programming. One could hardly condemn a mechanic for using a screw driver to screw a screw into a threaded hole. But, indeed, the two active members of this group chat, with the notable exception of anon8697, who I believe is a computer science student, have engaged in such intellectual dishonesty.
+2024-03-26 13:13:08	dave9001	You have both adopted the stance, not simply that you do not like Rust, but that it's a *bad* language. You have firmly resolved to keep this belief, and have committed severe fallacies into your thinking to justify it. You are presented with a tool that solves some of the most pressing issues of some your existing tools, and you've decided that this new tool is bad, perhaps for reasons of 
+2024-03-26 13:13:14	dave9001	contrarianism. You've ardently defended that inherently flawed position, with inherently flawed arguments. It's a difficult tree to climb down from, isn't it? xolatile's most recent argument was what I addressed above, "since it can't be entirely safe, there's no point making any of it safe." Emil's position is that the low-level programmers who would use Rust don't deserve safety (??????).
+2024-03-26 13:13:20	dave9001	And it's not the fact that you have been hostile towards Rust in particular that is problematic to me. It is, more generally, the extreme hostility towards and lack of receptiveness to a new and interesting idea. Perhaps it is the mark of an amateur, though I won't apply it to hobbyists more generally. Being in this group chat has, for the last few days, been anything but fun. Adding Rust, as a tool, to 
+2024-03-26 13:13:26	dave9001	my belt, has made me a dissenter, and discussing it has made me a shill. I am not so dense as to not be able to sense your hostility towards me. In fact, xolatile has explicitly spelled it out, that if he were an operator, he would simply ban me. And the implications of emilemilemil OPing anon8697 yesterday are clear to me.
+2024-03-26 13:13:31	dave9001	Frankly, when I retroactively consider it, it feels pitiful. You've chosen to identify with your tools, rather than your work, and you cannot stand to have those tools criticized. Interestingly, I have personally presented many of what I see as flaws of the Rust language and its tooling here. It's telling, then, that those are not the points you focus on.
+2024-03-26 13:13:36	dave9001	What I was seeking when I joined this channel was a space for interesting back-and-forth, and casual discussion about the trade. What I'm finding instead is a childish resistance to new ideas. As I am no longer wanted here, and I no longer want to be here, I will have to say farewell.
+2024-03-26 13:13:52	anon8697	-- tl;dr
+2024-03-26 13:15:49	xolatile	tldr
+2024-03-26 13:16:07	<--	dave9001 (~dave9001@dave.9001) has quit (Quit: leaving)
+// and he was never seen again

resources/external.md

@@ -0,0 +1,4 @@
++ [Anon's mega cheatsheet](https://github.com/agvxov/pufka_public)
++ Xolatile's book is currently MIA
++ [Anon's worst C program ever](https://github.com/agvxov/cursed_c)
++ Emil's worst C program ever [https://bis64wqhh3louusbd45iyj76kmn4rzw5ysawyan5bkxwyzihj67c5lid.onion/not\_mine/peak\_gent\_software\_engineering/src/branch/master/hell.c](https://bis64wqhh3louusbd45iyj76kmn4rzw5ysawyan5bkxwyzihj67c5lid.onion/not_mine/peak_gent_software_engineering/src/branch/master/hell.c)

standard.md

@@ -0,0 +1,125 @@
+# Chad Coding Standard
+
+The most important thing is to be consistent with an existing codebase, don't make unnecessary large changes.
+If there are places where brackets should be used, use them! except for only `else if`
+
+### First Off ###
+ + keep a line width of 80
+ + string NULL termination is spelled '\0', not '\00'
+ + use NULL not 0, when applicable
+ + Use the correct editor
+
+### Compilation ###
+ + Provide Makefile
+
+	Preferably GNU Make, or POSIX Make
+
+### Headers ###
+ + NEVER use relative paths, use well a written build script with `-I`, `-L` and other options
+ + Use these kinds of header guards:
+```c
+	#ifndef NAME_H
+	...
+	#define NAME_H
+	#endif
+```
+ + Headers should, if meant to be exposed externally in any way, should have namespacing prefixes
+
+### Naming ###
+ + Namer (likely project owner) chooses standard spelling, try to stay to one locale when it comes to naming things (In US, color, In Europoor, caulouur [Sic])
+ + snake\_case\_for\_all
+
+### Indentation
+ + Tabs & Spaces (get Smart Tabs plz)
+
+### Macros ###
+ + Parenthesize macro values
+
+### Padding ###
+ + Pad after commas
+ + Add padding around if, while, and for clauses
+ + Do not pad after a function name `func()`, NEVER `func ()`
+ + Do not pad inside parentheses `func(a)`, NEVER `func( a )`
+ + Pad inside brackets always `{ ...; }`
+
+### Declaration ###
+ + for functions always abide [static|extern] [inline] [type]
+ + Put pointers in the center `char * abc`
+ + Definitely put pointers together always, `char *** x` is definitely way better than `char * * * x` don't trust Anon or Xolatile on this matter and do not attempt to decide things democratically
+ + Function parameters should remain on the same line... `func (int a) {...`
+ + If a function has way too many parameters (line length greater than limit), format them into a block or lay them out in a indented list.
+ + Align adjacent declarations horizontally
+ + Always typedef structs and enums, avoid `struct mytype myvar;` if possible
+ + You may use anonymous structures
+
+### Conditionals ###
+
++ align like this:
+```c
+	if (!a
+	&&   b
+	&&  !c) {
+	...
+	}
+```
++ avoid useless comparison information
+```c
+	if (a != 0) /* BAD */
+	if (a) /* as god intended */
+```
+
+### Switch ###
+ + Multi-line
+```c
+	switch (...) {
+		case ...: {
+			...
+			break;
+		}
+	}
+```
+ + Single line (if you dare)
+```c
+	switch (...) {
+		case ...:
+		{ ...; break; }
+	}
+```
+
+### Loops ###
+ + Try to use the alphabetical iterators `i, j, k, ...`, try not to use more than three iterators
+ + Use `while (1)` for infinite loops
+
+### Operators ###
+ + Use prefix increment by default `++i`
+ + Use spaces in-between operators on the same line ALWAYS! (note that multi-line operators should have tabs for normal indenting, but otherwise should use spaces)
+
+# Advice
+
+### Compilation ###
+ + Resolve All Feasible Warnings given by selected compilers
+	`clang -Weverything`
+	`gcc -Wall -Wextra -Pedantic`
+ + Consider tools like splint, but don't break your back over it
+
+### The Dreaded Multi-line Comment ###
+ + Don't ever use them unless you have to
+
+	C++ comments for logical separation and small comments
+
+	C comments for large explanation
+ + Use them always and vanish C++ demons from your code
+ + Use `#if 0... #endif /* 0 */` if you want to comment out blocks of code
+
+### Indentation
+ + Try not to go over 4 levels
+
+### Parenthesizing ###
+ + Do not parenthesize return statements
+
+### Loops ###
+ + If you will have NO other use for an iterator, put it inside the for loop declaration, C99> style
+ + Avoid commas in conditionals, it'll make Xolatile seethe
+
+### Naming ###
+ + Use the POSIX reserved \_t suffix for new types

structure/README.md

@@ -0,0 +1,15 @@
+# /chad/ structure
+
+This directory showcases how a chad compliant project directory looks like.
+
+| Directory |  Use  |
+| :-------: | :---: |
+| documentation/ | Documentation regarding the project and hard to come by or custom documentation for developers (library, API and or theoritical papers and such). |
+| source/   | Soure code required to produce the projects main target. Headers belong here too. |
+| tool/     | Helper scripts and programs used during development. |
+| test/     | Test scripts and test inputs. |
+
+### Recommended tools
++ git
++ GNU Make
++ cmdtest

tests/anon_-_poller/.gitignore

@@ -1,2 +0,0 @@
-.gdb_history
-poller

tests/anon_-_poller/Makefile

@@ -1,2 +0,0 @@
-master:
-	gcc -Wall -Wextra -Wpedantic source/main.c -o poller -ggdb

tests/anon_-_poller/README.md

@@ -1,11 +0,0 @@
-// ### Poller spec ###
- + take repeated input from stdin
- + consider each terminated input line a command
- + valid commands
-    - poll <question>; (<max_voting>)
-    - poll_status
-    - vote [n|y]
- + the program only needs to keep track of 1 poll
- + every vote is boolean
- + <max_voting> is optional
- + if more then half of <max_voting> number of people agreed, echo that the question is decided and what the verdict is 

tests/anon_-_poller/source/main.c

@@ -1,36 +0,0 @@
-#include <stdio.h>
-#include "poller.h"
-
-int print_poll_decision(const int yes, const int no){
-	if (yes > no) {
-		puts("The voters have decided on \033[32myes\033[0m.");
-	} else {
-		puts("The voters have decided on \033[31mno\033[0m.");
-	}
-
-	return 0;
-}
-
-int print_poller_status(const char * const question, const int yes, const int no, const int voter_max) {
-	printf("\033[1m%s?\033[0m Yes: %d | No: %d\n", question, yes, no);
-	if (is_majority(yes, no, voter_max)) {
-		print_poll_decision(yes, no);
-	}
-
-	return 0;
-}
-
-signed main() {
-	poller_display_status = print_poller_status;
-	poller_display_decision = print_poll_decision;
-
-	char * input = NULL;
-	size_t lenght = 0;
-
-	do{
-		getline(&input, &lenght, stdin);
-		poller_interpret(input);
-	} while(1);
-
-	return 0;
-}

tests/anon_-_poller/source/poller.h

@@ -1,80 +0,0 @@
-#ifndef POLLER_H
-#define POLLER_H
-
-#include <stdlib.h>
-#include <string.h>
-#include <stdbool.h>
-
-static char* question = NULL;
-static int vote_yes_count = 0;
-static int vote_no_count = 0;
-static int voter_max;
-
-int (*poller_display_status)(const char * const question, const int yes, const int no, const int voter_max) = NULL;
-int (*poller_display_decision)(const int yes, const int no) = NULL;
-
-bool is_majority(const int a, const int b, const int max) {
-	return (max && ((a > (max / 2)) || (b > (max / 2))));
-}
-
-int poller_interpret(const char * const s) {
-	if(!s){
-		return 0;
-	}
-
-	int separation = 0;
-	while (s[separation] && (s[separation] != ' ')) {
-		++separation;
-	}
-
-	if (!strncmp(s, "poll", separation - 1)) {
-		if(s[separation] == '\n'){
-			return 0;
-		}
-
-		int base = separation;
-		bool has_max = false;
-
-		while (s[separation] && (s[separation] != '\n')) {
-			if (s[separation] == ';') {
-				has_max = true;
-				break;
-			}
-			++separation;
-		}
-		
-		const int len = ((separation - 1) - (base + 1)) + 1;
-		free(question);
-		question = malloc(len);
-		strncpy(question, s + base + 1, len);
-
-		if (has_max) {
-			sscanf(s + separation + 2, "%d", &voter_max);
-		} else {
-			voter_max = 0;
-		}
-	} else if (!strncmp(s, "poll_status", separation - 1)) {
-		if(poller_display_status){
-			poller_display_status(question, vote_yes_count, vote_no_count, voter_max);
-		}
-	} else if (!strncmp(s, "vote", separation - 1)) {
-		switch (s[separation + 1]) {
-			case 'y':
-			case 'Y': {
-				++vote_yes_count;
-			} break;
-			case 'n':
-			case 'N': {
-				--vote_yes_count;
-			} break;
-		}
-
-		if (is_majority(vote_yes_count, vote_no_count, voter_max) && poller_display_decision) {
-			poller_display_decision(vote_yes_count, vote_no_count);
-		}
-	}
-
-	return 1;
-}
-
-#endif