It is strongly recommended that before submitting you should run make clean

It is strongly recommended that before submitting you

This preview shows page 9 - 11 out of 14 pages.

It is strongly recommended that before submitting you should run make clean , then run the single command make , to ensure that your makefile builds all the public tests correctly. This is the situation in which your makefile has to work on the submit server– being able to build the tests when there are no executable or object files in the directory– so you should test it and ensure it works right in the same circumstances. Lastly, there are a lot of features of make that were not explained in class, because they are difficult for a beginner to use correctly. Consequently you are advised to avoid all features of make other than those covered in class. If you do use features of make not explained in class your submission may not compile on the submit server for technical reasons not worth fully explaining here, and the TAs will probably not be able to help you in office hours with your makefile. You are advised to just write a simple and straightforward makefile. 7 Memory checking and memory errors We are supplying you with a compiled object file named memory-checking.o , along with its associ- ated header file memory-checking.h . These files define two functions, setup_memory_checking() and check_memory_leak() , which have no parameters or return value. setup_memory_checking() will be called © 2013 Larry Herman; all rights reserved 9
Image of page 9
by our tests, and must be called before any memory is dynamically allocated; it will set up things to have the consistency and correctness of the heap checked. If it is initially called, and your code has any subsequent memory errors (such as overwriting beyond the end of an allocated memory region in the heap) the program will crash, consequently failing the test. If check_memory_leak() is called at any point it will print a message indicating whether there is any memory in use in the heap at all. Some of our tests will initially call setup_memory_checking() , and call check_memory_leak() after rmfs() is called on all Filesystem variables in use. If your rmfs() function (or any other function) is not freeing memory properly your program will report that there is some allocated memory in the heap, meaning a memory leak occurred, causing such tests to fail. If a user of your functions calls mkfs() on a Filesystem variable that currently contains some files or directories (meaning that it is using some dynamically-allocated memory) before rmfs() is called on it (in other words, calling mkfs() twice without an intervening rmfs() ), the effect will be that a memory leak occurs. There is nothing that your functions can do to detect or prevent this. As above, it is the responsibility of the user of your functions, if they want to avoid memory leaks, to call rmfs() on any Filesystem variables that have any contents, before calling mkfs() on them. This does not apply to the initial call to mkfs() , since a Filesystem has no contents before mkfs() is first called on it.
Image of page 10
Image of page 11

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture