In the robust library's add_to_queue function, the fields head and count of the queue head are not checked for consistency in that function. What problem might this cause?
The count field may have an inaccurate count of elements in the queue
The index where the new element is to be put might exceed the length of the queue
None; the checking is done in readref
If head is negative, the element to be added may overwrite another element in the queue
Which of the following are things to do in robust programming? (Select all that apply.)
- Check that parameters are valid when the function is called
- Check for references to outdated data
- Make parameters that can be checked for validity
- Once debugged, remove the checks for internal inconsistencies as they are no longer necessary
In the robust library, what happens if the queue array is full and the function to create a new queue is called?
- The library crashes as the index used is beyond the end of the queue array
- A new queue element is created after the end of the queue array, and the corresponding ticket is returned
- The function to create a new queue returns an error code
- The function to create a new queue silently ignores the failure and returns a bogus token
In the robust library, the token generation function qtktref does not check that the nonce is non-negative. Why not?
- Nonces are always positive
- It is only important that the nonce be unique
- The qtktref function ensures the nonce value cannot overflow
- A negative nonce indicates a library function has been called incorrectly
Which of the following is *not* a problem with the take_off_queue() routine in the fragile library?
- Its arguments are not checked for validity.
- Queue overflow may occur.
- Queue underflow may occur.
- The mod of the head field with the size field needs to occur before the head field is used to obtain an element, because incrementing it may produce an index 1 more than the index of the last element of the queue.
Why does the token include a nonce?
- To distinguish between a current queue and a queue that has been deleted
- To make a token harder to forge
- To make it unlikely that a random number passed as a token will in fact be a valid token
- To encode a checksum so the library can determine whether the token is valid
Which of the following is a property of fragile programming?
- Handling bad input gracefully
- Preventing abnormal termination
- Handling internal errors gracefully
- Enabling unexpected actions
Complete the sentence: a function with high cohesion __________.
- is more complex than one with low cohesion
- is more likely robust than one with low cohesion
- has no parameters
- performs several different independent functions
What is the relationship between programming robustly and programming defensively?
- Robust programming refers to the program, while defensive programming refers to how the user interacts with the program.
- They are opposites; a program written defensively can never be robust, and vice versa
- They are different; defensive programming means to program as if your program will be criticized, and robust programming means to program so that your program works as expected and handles errors gracefully.
- They are the same; defensive programming means to program as though your program will execute in a hostile environment, and robust programming is effectively the same thing