>Learn C http://cvsweb.openbsd.org/cgi-bin/c vsweb/src/ h

>>58886485
>Windows
leave

>>58886485
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.

>>58886611
What do you recommend instead of C?

>>58886611
>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.

>>58886611
Here have some fun

#include<stdio.h>
#include<stdlib.h>
#include<GL/glut.h>
#include<GL/gl.h>
#include<math.h>

#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));
}

>>58886659

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

>>58886627
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.

>>58886674
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.

>>58886637
Hey, I work at Amazon using Swift!

>>58886845
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?

>>58886611
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.

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

>>58887047
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.

>>58887098
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.

>>58887133
>>>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.

https://www.reddit.com/r/unixporn/comments/5nh1we/xfce_emerald_compizreloaded_neon84_1980s_retro/dcbvrkx/

>>58886524
:^)

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

>>58888495
>design patterns
>>>>/javagen/

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

>>58886611
Retard.

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

muh pointer pointer

void (* update) (void * data)

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

>>58886611
yes lets use javascript instead

>>58886845
is golang memory safe?

>>58886674
This code is sooo opengl2.0

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

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

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

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

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

>>58889247
>>58889252
>>58889267
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.

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

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

>>58889308
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.

>>58889308
No. That is stupid.
Do you put spaces around all of your unary operators?

printf ("whatever\n")l

array [10] = 20;

etc.

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

>>58889308
no thats gross
* must always be next to something

for types

Type* blah 

for dereference

*var = blah

>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.

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

>>58889346
Pointers are different than other unary operator.

>>58889356
Matter of opinion.
I find

struct* stuff

to be gross.

>>58889423
>>58889356
You mean

foo_t *bar

>>58889423
>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.

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

>>58889451

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.

>>58889580
>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.

>>58889615
>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?

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

>>58889651
>It works just the same in the end.

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

unsigned int * ptr1, ptr2

>>58889805
fixed

unsigned int * ptr, * ptr2;

>>58889805
I always take two lines to declare two pointers, even if they are of the same type.

unsigned int * ptr0;
unsigned int * ptr1;

>>58889850
you're taking style zealotry to new heights
congrats

i've rejected pull requests for doing this shit.

r8.

#include <stdio.h>

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

>>58889900
0/10
please use your imagination next time

>>58889936
How's this

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main (void) {
    int malloci;
    char *mallocstring;
    int *mallocreturn;
    mallocreturn = &malloci;
    for (malloci=1; malloci<=100; malloci++) {
        if (malloci % 15 == 0) {
            mallocstring = (char *) malloc((sizeof(malloci)+8));
            strcpy(mallocstring, "MallocBuzz\n\0");
            printf("%s", mallocstring);
        } else if (malloci % 5 == 0) {
            mallocstring = (char *) malloc((sizeof(malloci)+3));
            strcpy(mallocstring, "mal\n\0");
            printf("%s", mallocstring);
        } else if (malloci % 3 == 0) {
            mallocstring = (char *) malloc((sizeof(malloci)+3));
            strcpy(mallocstring, "loc\n\0");
            printf("%s", mallocstring);
        } else {
            printf("%d\n", malloci);
        }
    }
    malloci = 0;
    return *mallocreturn;
}

Never free.

>>58889886
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;
}

>>58890021
That is NOT visually appealing.

File: 1361918884095.png (42KB, 344x517px) Image search: [Google]

42KB, 344x517px

>>58890205
pff.
What do you even consider visually appealing.

File: 73961539153.png (101KB, 411x387px) Image search: [Google]

101KB, 411x387px

>>58886674
>>58889184
>>58889207
>>58889229
>mfw my old thinkpad is stuck to opengl 2.1

>>58886611
(You)

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

>>58886485
what the fuck the libmicrohttpd example is so badly formatted

some time i want to try writing plan 9 C

>>58886611
Watch out everybody we have a retard over here.

>>58886485
MinGW is not an IDE

>>58886611
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.

>>58886938
>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.

>>58887133
>>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.

>>58889356
>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