Learn C

>Learn C
cvsweb.openbsd.org/cgi-bin/cvsweb/src/
gnu.org/software/gnu-c-manual/gnu-c-manual.html
courses.csail.mit.edu/6.851/spring12/lectures/

>Do fun stuff with C
glprogramming.com/red/
gnu.org/software/ncurses/
gnu.org/software/libmicrohttpd/

>Windows IDE
mingw.org/wiki/howto_install_the_mingw_gcc_compiler_suite

Other urls found in this thread:

reddit.com/r/unixporn/comments/5nh1we/xfce_emerald_compizreloaded_neon84_1980s_retro/dcbvrkx/
cvsweb.openbsd.org/cgi-bin/cvsweb/src/
twitter.com/AnonBabble

>Windows
leave

Ambulances, breathing machines, etc are all expected to be reliable. We live in a time where software bugs kill people. Using a memory unsafe language like C is plain unethical. There are much better alternatives in this day and age. The only reason anyone would learn C in 2017 is to feel superior. Fuck anyone who codes in C.

What do you recommend instead of C?

>He clearly hasn't written anything more than hello world in java before
C is fun.
I program in swift all day for my job, when I get home I like to relax, crack open a bear and have fun with C-tan.

Here have some fun
#include
#include
#include
#include
#include

#define WIDTH 255
#define HEIGHT 255
#define DEPTH 4

static GLubyte texImage[WIDTH][HEIGHT][DEPTH];
static GLuint texName;
static GLuint time;

const size_t FRAME_SZ = WIDTH * HEIGHT;
const size_t TOTAL_SZ = DEPTH * WIDTH * HEIGHT;
const unsigned char MAX_COLOR = 255;

enum color_band {R, G, B, A};

float distance(float p1[], float p2[]);

int
genTex(void)
{
float center[2] = {WIDTH / 2, HEIGHT / 2};

for (int h = 0 ; h < HEIGHT; ++h) {
for (int w = 0; w < WIDTH; ++w) {
for (int d = 0; d < DEPTH; ++d) {
unsigned char px;
float point[2] = {w, h};
float dist = distance(point, center);
float circular_gradient = sin((1.0 - dist / HEIGHT) * 50);

float adj = center[0] - point[0];
float adj_over_hyp = adj / dist;
switch (d) {
case R:
px = 0.5 * circular_gradient * MAX_COLOR;
break;
case G:
px = circular_gradient * MAX_COLOR;
break;
case B:
px = 0.5 * sin(circular_gradient * 100 * (time % 5)) * MAX_COLOR;
break;
case A:
px = 255 - time;
break;
default:
px = 0;
}
int resolution = 1000;
float ang = acos(adj_over_hyp);
ang *= (float) resolution;
int ang_int = (int) ang;
ang_int %= (resolution / 2);
ang = ((float) ang_int) / (float) resolution;
px -= 200 * cos(ang * (time % 10));

texImage[h][w][d] = px;
}
}
}
}
float
distance(float p1[], float p2[])
{
return sqrt(pow(p2[0] - p1[0], 2) + pow(p2[1] - p1[1], 2));
}

void
display(void)
{
++time;
genTex();
glClearColor(0.0, 0.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(1.0, 1.0, 1.0);
glLoadIdentity();
glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);
glEnable(GL_TEXTURE_2D);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
glBindTexture(GL_TEXTURE_2D, texName);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, WIDTH, HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, texImage);
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0); glVertex3f(0.25, 0.25, 0.0);
glTexCoord2f(0.0, 1.0); glVertex3f(0.25, 0.75, 0.0);
glTexCoord2f(1.0, 1.0); glVertex3f(0.75, 0.75, 0.0);
glTexCoord2f(1.0, 0.0); glVertex3f(0.75, 0.25, 0.0);
glEnd();
glFlush();
}
void
update(int t)
{
display();
glutTimerFunc(50, *update, 1);
}
int
main(int argc, char *argv[])
{
time = 0;
glutInit(&argc, argv);
glutInitWindowPosition(0, 0);
glutInitWindowSize(800, 600);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB | GLUT_DEPTH);
glutCreateWindow("Trippy image gen 2: cpu bound real time image generation?!");
glutDisplayFunc(*display);
glEnable(GL_TEXTURE_2D);
genTex();
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glGenTextures(1, &texName);
glBindTexture(GL_TEXTURE_2D, texName);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, WIDTH, HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, texImage);
glutTimerFunc(50, *update, 1);
glutMainLoop();
}


>Meanwhile in your favorite ''high level''''' language you have to write 1000 lines of boilerplate NewObjectFactoryFactoryShitter code

Me, specifically, Rust. It is memory safe and its compiler errors force you to be careful with what you write. It is much less prone to memory bugs. But I am open to other memory safe languages, too. I am not advocating for Rust specifically, I am advocating for memory safety, and Rust happens to be an example.

>A good C programmer doesn't have to worry about this
I know you didn't say this but this is a response I'll get. Actually, you are not smarter than the thousands of engineers who make subtle errors just by making a typo. Heartbleed is a memory bug written by engineers that are smarter than you and I. It could have been prevented by using a memory safe language.

>My job requires C/my embedded system requires C
This is very unfortunate and I don't blame you.

I am not arguing with you because I don't use OpenGL, but it's funny you're implying that C requires LESS boilerplate code than any other language. I think you're shitposting though.

Hey, I work at Amazon using Swift!

Memory safety has been a known issue in C for ages, and for something like two or three decades people have been trying to build a language on the premise of "Like C, but safer". They succeeded in many areas of applications programming but failed utterly to supplant C in systems programming and a lot of library code.

Why do you think that is, and why do you think that this time it's different?

I hope you realize life-critical code is vetted and fuzz-tested out the ass before it gets burnt onto microcontrollers.

Also, many embedded shops won't let you use recursion or malloc, so you're safe from undefined behavior regardless.
Go read MISRA-C.

It may not be different this time. I'm fine with Rust dying as long as another memory safe language can take its place.

That's kinda my point though, no memory-safe language has ever taken C's place, despite lots of smart people trying for many years to do just that.

it's the vicious cycle of
>oh nice language, i'll wait a few years till it matures
>everyone thinks the same thing
>10 years pass
>nothing important is written in it
>it's compiler is still written in C because FUCK YOU

Also, fuck trying to write for a non-standardized work in progress language.

>>>it's compiler is still written in C because FUCK YOU
well at some point your tower of abstractions has to have a foundation under it. Eventually something needs to tell the CPU to shuffle bytes around, and that something isn't going to be memory-safe because the CPU isn't memory-safe.

reddit.com/r/unixporn/comments/5nh1we/xfce_emerald_compizreloaded_neon84_1980s_retro/dcbvrkx/

:^)

What are some best practices and effective programming patterns when using C? What are some pitfalls to avoid?

>design patterns
>>>>/javagen/

Shut the fuck up if you don't know what you're talking about.

Retard.

lol bro just fukin make it work
we arent writing nasa shit here u kno

muh pointer pointer

void (* update) (void * data)

So does this mean we'll continue seeing hilarious 0day vulnerabilities in C codebases for 40 years to come?

yes lets use javascript instead

is golang memory safe?

This code is sooo opengl2.0

Version 1, get with the times friends.
FUCK shaders and vertex buffers.
Immediate mode yolo

also
>tfw noone tried it out
it's pretty cool...
Playing with the constants in the image gen function is funi

Shaders and vertex buffer allow for greater control of what you draw though.
At the expense of having to write more shit of course..

immediate mode opengl code doesn't even run on the GPU anymore, it's handled entirely in software by the GL driver.

Even if this post is ironic, I think you should kill yourself.

IMMEDIATE MODE
Y
O
L
O

spoilers I know the theory behind 3D computer graphics, so I can write my own lighting shaders and whatever, but I like the simplicity of fixed function OpenGL. Simplicity is fun.

Anyone here write their pointers like this
int * ptr;
* ptr = 1;
if(* ptr)
printf("Hello");

?
I think it's very elegant. And it makes sense because it can be viewed as an extension of a type.

Then I hope you realize that no GPU actually runs your immediate mode code.

Gib me a break, I'm writing fun shit, in a way that I enjoy, not writing performance critical crap.

I hate people who do this.
Spaced out asterisks look like multiplication, so now this looks like pointer multiplication, which isn't even valid C.

No. That is stupid.
Do you put spaces around all of your unary operators?
printf ("whatever\n")l
array [10] = 20;
etc.

Why the hell do you post like a fucking child?
>Gib
>Yolo
Seriously, fuck off.

no thats gross
* must always be next to something

for types
Type* blah
for dereference
*var = blah

BRO CHILL OUT MY MAN
JUST HAVE SOME FUN AND PROGRAM FUN STUFF
ASK ME SILLY QUESTIONS
I WILL PLAY SILLY GAMES
FOR PROGRAMMING FUNIS IS MY AIM

Sup Forums is an 18+ website.

>its another "rust kiddies try to make their meme language stop being a meme making the same arguments every other failed language has done" episode.

hi qt
do u want to talk to me about why ur so angry...
;) im her for u
come on... don't u have a job user... things will get better...
do u have any funi code you can share in c
we can have fun together :))

You know the variable is a pointer so there's no confusion with multiplication.

Pointers are different than other unary operator.

Matter of opinion.
I find
struct* stuff
to be gross.

You mean
foo_t *bar

>Pointers are different than other unary operator
Why? The array example I posted is directly linked to pointers.
I think what you're doing is just incredibly inconsistent.

That's shit-tier.
Variables are declared like they're used. I use a pointer like *ptr, so I declare it like *ptr.

int * ptr;
is visually consistent with other data type like
unsigned int i;
long long stuff;
struct circle c;

You're right that it's somewhat inconsistent with the declaration of arrays but I don't really mind.
It's visually more aesthetic in my opinion.

>visually consistent
But it's not functionally consistent. It both confuses new programmers and makes it seem like you don't know what you're doing.

>But it's not functionally consistent.
Why isn't it. It works just the same in the end.

>It both confuses new programmers
Why should I care of people who don't know how pointers work?

...

>cvsweb.openbsd.org/cgi-bin/cvsweb/src/
why is that shit in there?

>It works just the same in the end.

No it doesn't.
What do you think this code does?

unsigned int * ptr1, ptr2

fixed

unsigned int * ptr, * ptr2;

I always take two lines to declare two pointers, even if they are of the same type.
unsigned int * ptr0;
unsigned int * ptr1;

you're taking style zealotry to new heights
congrats

i've rejected pull requests for doing this shit.

r8.
#include

int main (void) {
const volatile static unsigned long long int hi = 0;
if (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!hi) {
puts("Hi2u2!");
}
return 0;
}

0/10
please use your imagination next time

How's this
#include
#include
#include

int main (void) {
int malloci;
char *mallocstring;
int *mallocreturn;
mallocreturn = &malloci;
for (malloci=1; malloci

Visually appealing code is important.
void list_reverse(struct list * list)
if(list->length < 2)
return;

struct link * link0 = list->link;
struct link * link1 = list->link->next;
struct link * link2 = list->link;

while(link1) {
link2->next = link1->next;
link0->previous = link1;
link1 = link1->next;
link0->previous->previous = NULL;
link0->previous->next = link0;
link0 = link0->previous;
if(link1)
link1->previous = link2;
}

list->link = link0;
}

That is NOT visually appealing.

pff.
What do you even consider visually appealing.

>mfw my old thinkpad is stuck to opengl 2.1

(You)

Which c library to use for containers and directory handling
glib, apr, tbox, pjlib, plibsys, foundation_lib, qlibc ...

what the fuck the libmicrohttpd example is so badly formatted

...

some time i want to try writing plan 9 C

Watch out everybody we have a retard over here.

MinGW is not an IDE

You're always going to depend on "unsafe" code, because that's how computers work. Sure, write your code in Java or whatever high-level if you want, but there will always be "unsafe" low-level code underneath in C or asm used to implement the runtime, libraries, and OS environment. And even in a low-level language, you can provide "safety" by implementing it yourself - while still being able to avoid the overhead when you need to.

>Also, many embedded shops won't let you use recursion or malloc, so you're safe from undefined behavior regardless
So everything ends up being allocated on the stack or in bss, or do they have you use a custom allocator? And avoiding recursion and malloc don't make you immune to undefined behavior, there's lots of things that can cause that.

>>it's compiler is still written in C because FUCK YOU
A C replacement should at least be self-hosting. I mean, part of what a compiler does is basically string handling ,which C sucks at. If your C-killer has decent string handling and can do the same low-level stuff as C, then there's no reason not to write the compiler in that language.

>Type* blah
DO NOT do this. It makes newbies think the pointer declaration operator works like any other type qualifier, binding to the type rather than to the identifier.

why does GNU C abuse the preprocessor so fucking much