Stupid things C-""""programmers"""" do

void*

Real talk. Does this code invoke undefined behaviour? At first I thought it did, but now that I think of it, I'm not sure, because I'm pretty sure you're allowed to cast a pointer to a struct to a pointer to its first member without violating strict aliasing rules. Also I have a vague memory (probably wrong) that treating structs like arrays is actually okay as long as the underlying types match up. Does C guarantee the padding between the struct members is the same as the padding between the array members?

Attached: 1503774972761.png (930x1081, 1.25M)

it doesnt invoke undefined behaviour
maybe it could, but that can be avoided by the __attribute__ shit you can do to align, alias, pack, etc.

>++k
>++l
C programmers don't do that

Unlikely when all types are long but there might be padding in the struct so doing it like in the OP might to fill in the wanted values.

*(long *)((long)&some_struct[k] + (l * sizeof(long))) = l;

can a high level wizard explain me these casts, particularly the *(long *)?

well that retarded way of doing it.
*((long*)(some_struct + k) + l) = l;

(some_struct + k), get the current struct
cast it to long pointer and loop the longs in the struct.
dereference long pointer and set it to l.

I think this has more to do with your code than it does the C language. Why are you casting your pointer as a long, then adding adding a size to it, and then casting back to a long*? Shouldn't using C's built in pointer arithmetic is the way to go here?
*( (long *)(some_struct + k) + l ) = l

(void)

The only thing wrong with this code is assuming pointers are long.
Here's the fix
*(long *)((size_t)&some_struct[k] + (l * sizeof(long))) = l;

It's undefined behavior, because the compiler doesn't guarantee that the variables will be placed exactly like you defined it.

Imagine being this mad

Just get the address of the struct in the array, cast it to a long pointer, add the offset for the field, and dereference
struct some_struct_s
{
long variable_0;
long variable_1;
long variable_2;
long variable_3;
long variable_4;
long variable_5;
};

struct some_struct_s some_struct[10];

for (int k = 0; k < 10; ++k)
{
for (int l = 0; l < 6; ++l)
{
*(((long *)&some_struct[k])+l) = l;
}
}

You could even pack it to
((long *)&some_struct[k])[l] = l;

for (int k = 0; k < 10; k++) {
long *ptr = &some_struct[k].variable_0;
for (int l = 0; l < 6; l++) {
ptr[l] = l;
}
}

Why not init the struct once on the stack with initial values using temp = { ... } and then memcpy it 10 times into the array?

*things stupid C programmers do
FTFY
#include

typedef struct
{
long variable_0;
long variable_1;
long variable_2;
long variable_3;
long variable_4;
long variable_5;
} some_struct_s;

some_struct_s some_struct[10];
for (int k = 0; k < 10; ++k)
{
some_struct[k] = (some_struct_s){ 0,1,2,3,4,5 };
}

>this is how it works under the hood
It's not.

Using prefix and postfix operators inside more complex expressions is absolutely retarded, but apparently writing deliberately hard to read code is a dogma among Cniles.
Even K&R is full of this shit.

>that treating structs like arrays is actually okay as long as the underlying types match up
I'm not sure if you actually want to do that in real life as it makes your code quite unreadable but it's totally possible. And 'cause structs are bit-fields you can abuse this like so:

void f() {
struct {
char s1[3];
char s2[5];
} s;
strcpy(s.s1, "ok");
strcpy(s.s2, "flag");
printf("%s\n", ((char*)&s)[3]);
}

I had this snipped of code in an exam some time ago, you had to figure out what would cause the printf to print "flag".

What is the answer?
>pure chance because there is no grantee s2 comes immediately comes after s1
?

((char)%s)[3]
The answer is in the printf, the struct in the snippet creates an 8 byte wide bit-field, by accessing the 4th element of the struct you're accessing the first char of s2.

reminder that this is valid C.
typedef struct
{
int whatever;
int lmao[0];
} some_struct_s;
some_struct_s* s = malloc(sizeof(some_struct_s) + sizeof(int) * 5);
for (int k = 0; k < 5; ++k)
{
(*s).lmao[k] = k;
}

woops, it's an &, not %

I don't think bitfield is what you think it is. C does not guarantee the members are allocated next to each other and can add padding if it wants. Your instructor was dumb

B-but they told me that C is a l-low level language...

it is

Sure, if your computer is a PDP-11.

> C gives the freedom to do almost anything
> I decide to shoot myself in the foot
> It's C's fault
Imagine jumping from a roof, hurting yourself badly, and later blaming the government because it didn't outlaw stupidity.

You can tell the compiler to pack the structs

Took me a while to notice.

it is as low as you can get (including assembler)

C makes it too easy to shoot yourself in the foot, so you do it constantly by accident. There need to be safety measures in place.

>What is uintptr_t

>look at me
>i understand how memset works !!!!!
fuck off cs101 babby

#include
main(){
long long a = 33055139558552902;
puts(&a);
}

cdecl.org/

Better syntax couldn't be abused at all.
The most valid complaint against the C family is that it's ungodly redundant.
That doesn't mean the language is bad but its ignorant to pretend like it doesn't have problems.

C is a high level language, you're just retarded.

t. nigger

Program in C

memset(&some_struct, 0, sizeof(some_struct));

Phew, that was hard, OP!

It also doesn't do the same thing

It's just incrementing the variable by one, what's wrong with it?

why not just hide this garbage behind a lib?

struct_init(&faggot);

theres libs that do this shit for you, even the kernel has one so retards don't implement their own shit.

>(some_struct_s){ 0,1,2,3,4,5 }
pretty much, i just do the same and it looks much cleaner

cant do that with C89 though

1989 was 30 fucking years ago, though. Get a newer compiler.

i use gnuC anyways so it doesn't matter.

Have to use old version of XC8 compiler at uni labs for PIC microcontrollers, and it only supports C89.

Ended up having to rewrite all my struct initializations.

plaster your code with macros

these
OP is a retarded kid.