Lab 1 (clab-part1): Basic C Programming
This lab will get your hands dirty doing some basic C programming and debugging. The lab asks you to write several simple C functions in programs whose skeleton code are already provided for you.
Programming style:
For style, please read this style guide and follow the advice.
First, click on Lab1's github classroom invitation link (posted in Campuswire) and select your NYU NetID. Next, clone your repo by typing the following
$ cd cso-labs $ git clone git@github.com:nyu-cso-fa22/clab-part1-<YourGithubUsername>.git lab1
File modification
For this lab, the only files that you should modify are bitfloat.c, ptr.c and array.c. You may read other files but you must not change them..Complete the exercises in files bitfloat.c, ptr.c, array.c, in order. It is recommended that you complete and test the exercises in each file individually before moving on to the next. For example, suppose you have completed the exercise in bitfloat.c. Test by typing the following:
$ make $ ./clab_test Bit at pos 0 of int 1 should be 1 (returned 23) ---Start testing bitfloat.c get_bit_at_pos... Aborted (core dumped)From the above error message, you can see that my implementation of get_bit_at_pos in bitfloat.c did not pass the test. Debug and try again. Complete and test each part individually before moving on to the next one.
Once you've passed all the tests, you should see this (note that get_precision is a bonus problem):
$ ./clab_test ---Start testing bitfloat.c get_bit_at_pos...passed flip_bit_at_pos...passed get_most_significant_byte...passed sum_overflowed...passed get_exponent_field...passed get_precision...passed ---Test bitfloat.c Passed ---Start testing ptr.c set_to_five...passed initialize_ptr...passed swap_int...passed ---Test ptr.c Passed ---Start testing array.c array_sum...passed array_cpy...passed bubble_sort...passed big_to_little_endian...passed ---Test array.c Passed
Saving changes while you are working on Lab1
You should frequently save your work to protect against laptop failures and other unforeseen troubles. You save the changes by first "committing" them to your local lab repo and then "pushing" those changes to the repo stored on github.com
$ git commit -am "saving lab1 changes" $ git push origin master
The `-a` flag (as in the command `git commit -am ...`) tells git to add the changes you've made to existing files to the current commit. If you do not provide this flag, the changes you made to the existing files will not be committed. After you've pushed your changes with git push, they are safely stored on github.com. Even if your laptop catches on fire in the future, those pushed changes can still be retrieved. However, you must remember that git commit by itself does not save your changes on github.com (it only saves your changes locally). So, don't forget to type that git push origin master.
Debugging the lab
Below are some advice on how to debug common problems encountered in doing this lab:- Remember to recompile changed code. Whenever you've changed a file, always type make to re-compile before executing again.
- Read the test code in clab_test.c. You have to understand what kind of tests are being conducted in order to debug your code.
- Learn to use gdb. It is absolutely essential that you learn to use gdb. This tool is a must for helping you handle ``segmentation fault'',
which you'll see a lot when doing labs. Let's say you encounter "core dumped" when testing. Invoke gdb by typing:
$ gdb clab_test (gdb) bt
bt is the gdb command to print the stack trace which tells you where the problematic execution occurs and how the program got there. Here is a basic GDB tutorial that you should go through by yourself.
Handin Procedure
Follow these instructions.Grading
This lab is graded on two components:Correctness (80%): This objectively measures whether your program passes all the tests included in clab_test.c files. Note: We reserve the rights to potentially add additional tests if we see fit later. We will not disclose those newly added tests until after the grade has been released.
Style (80%): This is a subjective measure of how your code follows a consistent style and how readable it is. This is manually graded.