Freeing

Is there any real point in freeing memory these days? And I don't mean freeing memory for things that constantly grow and shrink in size. I mean freeing that one array that you malloc at the beginning of the program and you need it until the end of the program. What is the benefit of freeing it when it will be automatically freed by the operating system?

You go girl! Stick it to the man!

when it will be automatically freed by the operating system?
The operating system does not care about your internal allocation blocks, and will not call free(3) on anything; it simply drops the process's memory map.  Please be more careful about your ^B_B^CODE usage.

>>3
holy shit...
so that means all your data is still in memory???????????
FFFFFFFFFFFFFFFFFFFFFFFFF
THAT"S REALLY DANGEROUS

>>2
s/the man/The Man

>>4
Welcome to computers.

free(3) doesn't remove your data from memory either.

Actually most OSs actively zero our free memory, so they can give it faster to apps who request it (it has to be zeroed before a "new" program uses it, for security purposes).

>>7
that's pretty stupid. if you don't want your program's data to stay in memory you should zero it out yourself.

>>7
Both Windows and Linux leave the memory intact when you work in C.

>>7
Oh, that's why all my uninitialized variables have random values.

>>8,9,10
I don't think you know what are you talking about. All modern OS give zeroed out pages, both for RAM and for disk (this is why for some filesystems creating a file and writing to position 10000000000 takes a very long time: they don't support sparse files and have to fill it with zeros up to that position). It would be a security hole if they didn't. Note that this has nothing to do with malloc()/free(). A malloc() can give you memory with garbage in it, but rest assured that it's garbage from your own process, not some random stuff that other processes left over.

In the likely case you still don't believe it, just check http://download.microsoft.com/download/7/5/7/757a5c5c-1ad2-4774-9ffa-ec78052c42fb/scaling.doc (search for zero). As for Linux, see for example http://jno.glas.net/data/prog_books/lin_kern_2.6/0596005652/understandlk-CHP-9-SECT-4.html ("Linux goes one step further in the spirit of demand paging. There is no need to assign a new page frame filled with zeros to the process right away, because we might as well give it an existing page called zero page , thus deferring further page frame allocation. The zero page is allocated statically during kernel initialization in the empty_zero_page variable (an array of 4,096 bytes filled with zeros).", and the following paragraphs).

What really scares me is how oblivious people is to this kind of stuff. It should be second nature, like memory isolation. How can anyone think it wasn't like that is beyond me.

IHBT

>>11
There is no need to assign a new page frame filled with zeros to the process right away, because we might as well give it an existing page called zero page , thus deferring further page frame allocation.
I'm calling bullshit on this. The kernel gives a page frame filled with zeros to all processes? Then what happens if one of them writes to it?
tl;dr Linux is insecure, use BSD.

ALL HAIL BSD

>>11
Explain this then.

b:\>cat  memory.c
#include <stdio.h>
#include <stdlib.h>

main(){
    fwrite(malloc(0x100),1,0x100,stdout);
}
b:\>gcc memory.c -o memory && memory|hexdump -C
00000000  a0 27 93 00 28 0f 93 00  2e 61 70 70 76 65 72 73  |.'..(....appvers|
00000010  69 6f 6e 3d 31 2e 30 2e  30 00 43 6f 6d 6d 6f 6e  |ion=1.0.0.Common|
00000020  50 72 6f 67 72 61 6d 46  69 6c 65 73 3d 43 3a 5c  |ProgramFiles=C:\|
00000030  50 72 6f 67 72 61 6d 20  46 69 6c 65 73 5c 43 6f  |Program Files\Co|
00000040  6d 6d 6f 6e 20 46 69 6c  65 73 00 43 4f 4d 50 55  |mmon Files.COMPU|
00000050  54 45 52 4e 41 4d 45 3d  41 4e 44 52 45 59 2d 56  |TERNAME=ANDREY-V|
00000060  49 53 54 41 00 43 6f 6d  53 70 65 63 3d 43 3a 5c  |ISTA.ComSpec=C:\|
00000070  57 69 6e 64 6f 77 73 5c  73 79 73 74 65 6d 33 32  |Windows\system32|
00000080  5c 63 6d 64 2e 65 78 65  00 43 55 44 41 5f 42 49  |\cmd.exe.CUDA_BI|
00000090  4e 5f 50 41 54 48 3d 43  3a 5c 43 55 44 41 5c 62  |N_PATH=C:\CUDA\b|
000000a0  69 6e 00 43 55 44 41 5f  49 4e 43 5f 50 41 54 48  |in.CUDA_INC_PATH|
000000b0  3d 43 3a 5c 43 55 44 41  5c 69 6e 63 6c 75 64 65  |=C:\CUDA\include|
000000c0  00 43 55 44 41 5f 4c 49  42 5f 50 41 54 48 3d 43  |.CUDA_LIB_PATH=C|
000000d0  3a 5c 43 55 44 41 5c 6c  69 62 00 44 46 53 54 52  |:\CUDA\lib.DFSTR|
000000e0  41 43 49 4e 47 4f 4e 3d  46 41 4c 53 45 00 46 50  |ACINGON=FALSE.FP|
000000f0  5f 4e 4f 5f 48 4f 53 54  5f 43 48 45 43 4b 3d 4e  |_NO_HOST_CHECK=N|
00000100

b:\>

IHBT as in ``I have been trolling''?

>>14
hot gay sex

./malloc | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100

b:\>
wat

>>14
It's from your own process. Probably some memory left over from the C library's initialisation, judging by the presence of environment variables. Step through it right from the start (before main() gets called) in a debugger and you should find out why.

>>18
before main() gets called
wat

>>19
How are you fucktards even able to wipe your own ass, let alone smear your fucktardness all over the internet?

>>12
Are you trolling me, bro?

ITT: GODDAMN FIRST YEARS (except for the informative guy)
SAGE THIS SHIT.

>>22
ITT: Eternal September

>>19
All sorts of stuff happens before main() or WinMain() is called. Look:

http://img267.imageshack.us/img267/5263/notepad1nn4.png
http://img368.imageshack.us/img368/71/notepad2wo6.png
http://img118.imageshack.us/img118/849/notepad3dz5.png

>>14
IS DAT SOME CYGWIN?

it might be doing some hacking as apart of the cygwin environment. like loading cygwin.dll or whatever it is that programs built under cygwin seem to need

>>12
It's called "copy on write". If a process tries to write to the page, it gets its own version but if it only reads it or never accesses it, the shared copy is used.

Yeah yeah IHBT, but some most people here really don't know jack shit.

>>26
Speak for you're self, buddy.

>>27
You're not funny. Go away.

>>27
No you are self.

>>26
it really is just you though

>>28
You're
Sigh, it's a shame prog is filled with retards who don't even know basic grammer.
You're = possessive, as in "You're jacket is green"
Your = contraction, as in "Your not funny"
Try learning some basic grammer before posting again, loser.

>>31
You're not funny. Go away.

>>32

"GRUNNER"

>>32
I am seriously going to fuck you up - as in physically cause you pain, suffering, and disability. Want a preview? Go watch Blade, or Blade II - the same style of martial arts he's doing there is what I study. You're going to get one free lesson, "buddy" and I promise you it will be instructional.

>>34
Wow, you managed to post something that hasn't been posted fifty times already today. I'm almost impressed.

>>34
And before you say it, I know it's copypasta, but at least you're expanding your horizons just a little bit.

>>31
most retarded wannabe-meme of all time

I don't think you know what are you talking about. All modern OS give zeroed out pages, both for RAM and for disk (this is why for some filesystems creating a file and writing to position 10000000000 takes a very long time: they don't support sparse files and have to fill it with zeros up to that position).
i'm >>8 and i didn't say operating systems don't do that. i said they shouldn't.

It would be a security hole if they didn't.
no, it'd be a security hole if your program relies on non-standard features of the operating system. if you have sensitive data in memory and want it to not stay there, you should zero it yourself.

>>27,31,34,35
gb2/pr/

>>35
im a different person to the person u were responding too

>>39
Coulda fooled me.

>>40
Coulda
Pronounced ``cudder''

>>38
no, it'd be a security hole if your OS fails to provide the standard security features all programs rely on.  A program should reasonably expect that its memory is inaccessible to other users, no matter how or when the access attempt is made.

>>42
Oh dear.

A program should reasonably expect that its memory is inaccessible to other users, no matter how or when the access attempt is made.
a program should expect that anything it leaves in memory is accessible to anyone. any program that fails to handle it's own sensitive data properly is insecure. pretending all data is sensitive and having the operating system take care of it makes the operating system slow as fuck. having programs take care of their own sensitive data works much better.

>>42
This is why you overwrite sensitive data with random bytes after you no longer need it.

>>43-45
How the fuck is a program supposed to ``handle its own sensitive data''?  If an OS leaves memory readable by others, there is nothing the program can do to protect it.  The entire point of a multi-user operating system is to isolate privileges, including data access.  And yes, all data is sensitive unless it has been explicitly shared.  It is absolutely ridiculous to expect every program to know or care just how the user feels about a particular memory block the moment it is initialized.

Also, IHBT.

I mean, I should at least get to pick the value the memory is filled with before I get it.  I like my unallocated memory to have all ones.

IHBT as well.

>>46
the OS should protect the memory from being read by other programs while the program is using it, but once the program says it's done with it, the operating system should be able to hand that memory off to the next program that needs it without having to guess whether the data in that memory is sensitive. if the data is sensitive, the program should overwrite it before giving it back to the operating system.

Desu DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU   DESU DESU DESU.