Reviewing code at work

Its not the right size, its a struct

No, code with UB has a problem - that modern compilers will compile it, a lot of the time without warning. So when your app crashes you say "Welp works for me ;P"

pStructB = (STRUCT_B*)(pStructA + 1);

Attached: gigachad.jpg (1068x601, 65K)

char *c = (uint_32) malloc(50);

-Wall

Attached: 800.jpg (2048x2048, 478K)

You're probably not as smart as you think if you're working at a place like that.
>unironically using C

>Stupid people use C because you can't use C

struct pStructB * = (struct STRUCT_B *) malloc(sizeof(struct pStructB))

sue me

Attached: 1568197539075.jpg (540x540, 52K)

see, this example made it obvious on second glance what OP's snippet was doing. amazing what well written code will do.

>struct pStructB * = (struct STRUCT_B *) malloc(sizeof(struct pStructB))
jeeze mcgeeze I did not expect myself to actually be suable, sorry
struct pStructB * = (struct pStructB *) malloc(sizeof(struct pStructB))

>not even remotely equivalent
Neck yourself, pedo.

If you're reviewing that kind of code at work then you have to wonder what the hiring standards are like.

(jesus christ)

Jow Forums is not good for one's health

Is that Caitlyn? Kawaii~

It was obvious what OP's snippet was doing.

shouldn't it be "struct STRUCT_B* pStructB = ..." ?

No.

what is that piece of code supposed to do?

Attached: 1547516190577.png (586x557, 66K)

he is trying to declare a pointer to a STRUCT_B, no?

It creates a pointer to struct B that is assumed to be located right after struct A in contiguous memory

This
>contrived
No, it is how most packet formats and many file formats are constructed

yes it should

#include

struct STRUCT_A{};
struct STRUCT_B{};

int main()
{
STRUCT_A a;
STRUCT_B b;

STRUCT_A* pStructA = &a;

struct pStructB = (STRUCT_B*)(int64_t(pStructA) + sizeof(*pStructA));

return 0;
}

error: expected unqualified-id before ‘=’ token
struct pStructB = (STRUCT_B*)(int64_t(pStructA) + sizeof(*pStructA));

This is C retards

>>So when your app crashes you say "Welp works for me ;P"
People program software because they need it to do something for them. So, if it just werks for you, why bother?
Do you have autism user?

gcc reports same error
tried with both c90 as well as c11.

Does it actually compile for you?

>People program software because they need it to do something for them

Are you unironically retarded?

OP pointed out the blatant problem here And yes, I do understand that you are deliberately going for the low-hanging fruit since you are unable to grasp the question at hand

clearly i hadn't seen that.
Why didn't you just reply with that from the begging?

>you are deliberately going for the low-hanging fruit
do you actually have autism or something?

const B = new B();

Wow so hard.

what does
int64_t(pStructA)
do?

i don't even understand what is going on here. what is this code even supposed to accomplish?

effectively casts pStructA to int64_t.
The code initializes a pointer to struct b by taking the address of a struct a and adding the size of strut a to it, whihc only works if the two struct are stored consecutively in memory

Cast it to an integral type rather than a pointer type, otherwise adding sizeof(*pStructA) would add sizeof(*pStructB)*sizeof(*StructA)" to the address pointed to

The upcast is dumb (what if it's a 32-bit process?)
Use pointers as they are supposed to be used

i see, thanks. i've always just calculated the offset and stored it in an int to be added to the memory block base pointer. i guess OP works with a pointer slinging code cowboy.

In the normal vernacular, it means turning an int64_t variable to pStructA type

So you can't use pointers, just like the person in OP.

He is not a "pointer slinging code cowboy" (normal programmer?) but a retard like you.

Produces a constant of type int64_t (a signed integer occupying *exactly* 64 bits in memory) with the value of pStructA

>what is this code even supposed to accomplish?
int64_t(pStructA) address of pStructA
int64_t(pStructA) + sizeof(*pStructA)) address of the first open byte after pStructA
(STRUCT_B*)(int64_t(pStructA) + sizeof(*pStructA)) pointer to the first open byte after pStructA
pStructB = (STRUCT_B*)(int64_t(pStructA) + sizeof(*pStructA)); storing a pointer to the first open byte after pStructA

weird. i didn't know you could cast things that way. i've always used
(type)ptr
is there a difference?

pStructB = (STRUCT_B*)(pStructA + 1);

vs

pStructB = (STRUCT_B*)&pStructA[1];

not him but i think type(ptr) is safer because you can only do it if type can be initialized from ptr's type.

whereas i think (type)ptr will attempt to do the equivalent of c++'s std::reinterpret_cast(ptr) (which will cast no matter what - aka very unsafe) if it has no other options.

false, they are synonyms and both of them return a rvalue.

???

>If you are adding to a pointer, you are adding to the address pointed to in increments of the size of the type pointed to
There

Add 1 to a char* pointer and you are pointing at the second byte.
Add 1 to an int32* pointer and you are pointing at the second integer, i.e. 4 bytes past the first byte.

This is analogous with how indexing in arrays is

If you have long statements of struct pointers you can cast them to integral types to avoid pointer arithmetic. In the case of "get me whatever is following STRUCT_A" there is no need, since for example does exactly that

I would also not upcast to 64-bit because if the architecture is 32-bit and not 64-bit, your resulting statement will be a 64-bit value (your upcasted value is 64-bit, but the pointer types are all 32-bit) which is then truncated to the 32-bit assigned pointer. A decent compiler will warn about this.

GCC does what you would expect. Just don't try to use in other compilers

i understand pointer arithmetic, i'm just not so autistic that i care about undefined behavior. i pretty much do whatever is most fun at the time and if it breaks later then somebody else gets stuck fixing it anyway.

cool, thanks user.

That's simply wrong

Do you have braindamage or something?

People younger than 25 years are better at programming. They have more fluid intelligence. You are a coping old boomer.

>fluid intelligence
lmao

Attached: 1508417922085.jpg (851x714, 80K)

>fluid intelligence

That leaked out of your ears?

struct pStructB =
even this is gibberish. people who submit code for review and do not check if it even compiles locally should be shot.

>fluid intelligence

That's a yikes from me

Attached: 1527289571356.jpg (625x773, 132K)

...