me too thanks

+ashikombat some more vids of this series are coming :)

awesome

Γειά σου ρε stratan master των pwners !

+SonKomischerTyp cool! What is VOL?

LiveOverflow It's the Virtual Object Layer which catches the API calls from HDF and forwards them to the actual objects in memory. I wrote my plugin to optimize execution on a cluster so it used shared memory. Quite a cool project to work on :)

+SonKomischerTyp ah awesome. Sounds like a cool project. So you also had to deal with concurrent access and make it safe?

+dyslexicunt yeah thanks for pointing that out! Actually didn't think about that during writing the script :D I would hope nobody would rely on something I say this blindly. Instead I hope I could make the heap a less scary beast for exploration :)

That's ok, just thought it might help someone in the distant future who's screaming at gdb wondering why things aren't where they thought they are! (I spend a fair amount of time doing that myself) Looking forward to the next vid :)

I don't understand what you mean by packed and unpacked structs, can you maybe give some examples/hints?

+Borgimanio Sure :) Say i delcare a struct like this on an x86-32 bit platform: struct foo { u32 age; // 4 bytes u8 first_name; // 1 byte u32 *ptr // 4 bytes }; Looking at this, you would expect the struct to be 4+4+1 (9) bytes big and the elements contiguous in memory. You'd be wrong, however. The compiler would, in this case, silently perform this on your behalf: struct foo { u32 age; // 4 bytes u8 first_name; // 1 byte *+ 3 bytes of padding* u32 *ptr // 4 bytes }; Why does this happen? Because unaligned memory accesses are _bad_ for performance. The compiler will help you and pad out elements in your structure like this to ensure the next access (*ptr in the above case) will fall on a natural address boundary; a natural address boundary on 32 bit simply being an address evenly divisible by four. However there are some occasions where we dont want the compiler to 'help' like this, and we want it to leave our data packed exactly as it we've delcared it. This, is a packed struct. Nore simply put it's a struct which you have explicitly told the compiler you do NOT want to pad out. You do this with a compiler directive which, in gcc for example,looks like this : struct __attribute__((__packed__)) bar { u32 age; // 4 bytes u8 first_name; // 1 byte u32 *ptr // 4 bytes }; This explicitly informs the compiler not to meddle with the alignment and to keep the elements exactly contiguous in memory. Let it be said that you generally want to avoid doing this for the performance reasons given.

+dyslexicunt Thank you very much for your explanation! What could be possible reasons that someone doesn't want it to be unpacked? Perhaps if one has many structs and wants to save memory and doesn't care about speed?

+Бојан Драшко ah yeah makes sense. I will do it in a couple of days

yes

Yes please

The dark looking one is Sublime

In this program yes but in larger programs the mallocs would allocate a lot more of space (for example malloc(1000)) so the 8 bytes (blank space and size) aren't that big of a deal.

+Dima Kalchenko ;)

Pointer is a variable like other variables but what makes it different is that it points to a memory location and that memory locations contetnt can be read by dereferencing the pointer. So if it was a char arr[some size]

@@shobhitdogra7924 On my PC I can write f2->name = "Hello World"; and it compiles and runs correctly. I can also write char* text = "Hello World"; and it compiles and runs correctly. I am using gcc compiler. I see what you mean though, now I am a little bit confused as to why it works, because if I try to do the same thing with ints or any other type, it doesn't work, I get a segmentation fault. For instance, if I write int* arr = {1, 2, 3}; printf("%d ", arr[1]); This will not work, and it should not work, arr is a pointer, it is not an array. I can use that pointer to manipulate an array or read from an array but the pointer itself is not an array. It is just an 8 byte number which is a memory address of some other variable, or struct, or of another pointer. If I write the previously mentioned code, compiler assumes that I wanted ar to point to the memory address of 1, because 1 was the first number I wrote. However, I can write char* text = "Hello World"; and it will compile and run. I don't understand why I am not required to write char text[12] = "Hello World"; char* ptr = text; If I wanted a pointer to Hello World. In other words, what you are saying makes sense to me but that's not how my compiler works.

I don't know if you ever figured this out on your own, but in C a string between two quotes gets placed in memory somewhere, depending on platform and compilation options will tell you where, and you're merely assigning a pointer to this space that was allocated for you. So char *s = "Hello, World!"; will already have the space allocated for the string. In most cases you can't modify that space, and that is indeed standard behavior, but you can do char s[] = "Hello, World!"; and make it modifiable, but at a set length.

@@anon_y_mousse By now I know this. When posting previous comments I probably thought you have to write char string[20]= "this is a string"; And then you could write char *ptrToString = string; Or something to that effect. I was confused why writing a string can work in any other way than this way. char string[20] part takes 20 bytes on the stack in which you can put characters and the null character in the end, then char* ptrToString can point to the place in the stack where this array of char begins. So, writing char* s = "some text" ; did not make sense to me. In my mind, it would be logical that you first have to write char string[10] = "some text" ; and only then char* ptrToString = string; This is how int, double, float etc. work. You can't write int* arrayPtr = {0, 1, 2, 3, 4}; You have to write int array[5] = {0, 1, 2, 3, 4}; int* arrayPtr = array; I know by know that you are allowed to do this with char* And the example from the video makes sense now. When you are just writing char* string = "This is a string"; in the main function, compiler can put the chars and null in the end on the stack, no problem. If you make a strut with char* on the stack, compiler can again put those string bytes in the current stack frame (which means these bytes are lost after you exit the function). Still, no problem. However, when you are putting a struct on the heap then the compiler doesn't know where to put this array of bytes which represents a string. That's why in this case when you are allocating a struct on the heap you have to provide a place in memory where to put the bytes of the string. You have to either malloc that memory or just set the char pointer of the struct to be pointing to some place in memory where you have already stored the bytes of the string.

@@anon_y_mousse But I still don't know the difference in modifiability when it comes to char* str = "some text; And char[] str ="some text"; I haven't done much C in my life so I never noticed that the first one isn't modifiable. If it really isn't modifiable (I have no reason to assume you are lying) then why is that?

Because the whole row is 16 bytes (including the blank space at the start and the size itself).

0x21 has the last bit set (as opposed to 0x20). That is the `prev in use` bit, which means that the block before it is in use (is allocated). Which means if you ignore that metadata bit, the size is still 0x20. I have kinda ignored that for this video, to keep it simple. Just keep watching the Heap videos, it will be explained :)

@@LiveOverflow only vid on here which actually explains the internals on malloc. Great job! A noob question. Why is the block size double of the allocated bytes?

Shouldn't it be allocated-size+8 bytes (2 words)?

Finally! This has always bothered me when people say char, like to burn, instead of care. It's an abbreviation of character.

ع المطبخ