Titi Anggono <[EMAIL PROTECTED]> wrote: > I allocated memory to one array, which stores data from > one file,
Are you trying to read a whole file? If so, why? > and I made a condition that if one data being > read using fscanf() is larger than the threshold value > the program close. > > I just read that it is our responsibility to release > the memory if it is not required. Only if it is dynamically allocated. Since you haven't shown any code, most of the replies have assumed this. You mention fscanf and free, so I could also presume you're using C. C++ has additional allocation/ deallocation methods and issues. > Oke, I understand that and I can put free() at the end > of the code. But, I made a condition so I put exit() > before the free(). I wonder if exit() frees the memory No, exit() will call registered atexit() functions, close open streams, remove tmpfile-s, but it will not otherwise call free on dynamically allocated objects. > or I have to put free() also inside the condition. It's usually good practice to free anying you allocate. This avoids memory leakes and makes code more generally portable. Functions intended to be portable, e.g. in a library, should generally not call exit themselves, instead they should return and leave it to the caller to decide what to do. But if the program is simply exiting, then it's not uncommon to exit without free-ing. This is sometimes done deliberately since deallocating a large number of objects can take some time; time which the end user may not appreciate. Of course, it is entirely system specific whether the host (in a hosted C implementation) will reclaim memory resources if the program exits without free-ing. But then, the same technically applies to static objects. Fact is, on modern operating systems, the O/S will reclaim resources when the program exits. Having said that, the old Mac OSes where a reasonably recent exception (albeit only in extreme conditions.) -- Peter
