As you know, the C programming environment contains a standard library. The facilities provided in the standard library are declared in header files. One of those header files is string.h; it contains the declarations of "string functions," that is, functions that perform operations on character strings. Appendix D of the King textbook, Appendix B3 of the Kernighan and Ritchie textbook, Chapter 13 of the Harbison and Steele textbook, and the UNIX "man" pages describe the string functions. The string functions are used heavily in programming systems; certainly any editor, compiler, assembler, or operating system created with the C programming language would use them.
Your task in this assignment is to use C to create a "Str" module that contains versions of the most commonly used standard string functions. Specifically, design your Str module so it contains these functions, each of which behaves the same as a corresponding standard C function:
Str Function Standard C Function
Str_getLength() strlen() Str_copy() strcpy() Str_ncopy() strncpy() Str_concat() strcat() Str_nconcat() strncat() Str_compare() strcmp() Str_ncompare() strncmp() Str_search() strstr()
Use "design by contract." Design each function comment so it describes that function's "checked runtime errors." Design each function definition so it calls the assert() macro to enforce those checked runtime errors. (In that way your Str functions should differ from the standard string functions.) Specifically, design each function definition so it calls assert() to make sure that none of its pointer/array formal parameters is NULL.
Do not add any other calls to assert() to your code. But consider whether it would be possible to do so. In particular, provide answers to these two questions in your readme file:
Place the Str module's interface in a file named str.h. You may use either array or pointer notation in the interface. Use the "#ifndef...#define...#endif" construct to protect your str.h file against accidental multiple inclusion.
Create two implementations of your Str module. Place the first implementation in a file named stra.c. Design the function definitions in stra.c such that they use array notation, and not pointer notation. For example, in stra.c you might define the Str_getLength() function like this:
size_t Str_getLength(const char pcStr[])
{
size_t uiLength = 0U;
assert(pcStr != NULL);
while (pcStr[uiLength] != '\0')
uiLength++;
return uiLength;
}
(Note that the type of uiLength is size_t. The type size_t is defined in the standard header file stddef.h. It is a system-dependent unsigned integral type that is large enough to hold the length of any string. Typically it is defined to be identical to either unsigned int or unsigned long. On hats, it is identical to unsigned int. Several of the standard string functions use type size_t, and so several of your functions should use it too.)
(Note that the initial value of uiLength is 0U. As you may know, the "U" suffix indicates that the literal is of type unsigned int instead of int. Simply initializing uiLength to 0 works because C allows initialization of an unsigned int variable with an int literal. However, as a matter of style, we recommend that you avoid mixing types in that manner.)
Place the second implementation in a file named strp.c. Design the function definitions in strp.c such that they use pointer notation, and not array notation. For example, in strp.c you might define the Str_getLength() function like this:
size_t Str_getLength(const char *pcStr)
{
size_t uiLength = 0U;
assert(pcStr != NULL);
while (*(pcStr + uiLength) != '\0')
uiLength++;
return uiLength;
}
We encourage you to define the functions in strp.c more efficiently, by moving beyond a simple translation of a[i] to *(a + i). For example:
size_t Str_getLength(const char *pcStr)
{
const char *pcStrEnd = pcStr;
assert(pcStr != NULL);
while (*pcStrEnd != '\0')
pcStrEnd++;
return (size_t)(pcStrEnd - pcStr);
}
This assignment does not focus on efficiency. Nevertheless, your functions should not be grossly inefficient. For example, a function is grossly inefficient if it traverses a (potentially long) string more than once when a single traversal would suffice.
Design your Str functions such that they do not call any of the standard string functions. In the context of this assignment, pretend that the standard string functions do not exist. However your functions may call each other, and you may define additional (non-interface) functions.
Beware of type mismatches. In particular, beware of the difference between type size_t and type int: a variable of type size_t can store larger numbers than a variable of type int can. Also beware of type mismatches related to the use of the "const" keyword.
In your assignment solution you may use any of the definitions of the Str_getLength() function given in this assignment specification.
Code that you can use to test your Str module is available in the file /u/cos217/Assignment2/teststr.c.
Create a "readme" text file that contains:
Submit your work electronically on hats via the command:
/u/cos217/bin/i686/submit 2 str.h stra.c strp.c readme
We will grade your work on correctness and style. Correctness is defined by the previous sections of this assignment specification, and by the C89 specification.
Style is defined by the rules given in The Practice of Programming (Kernighan and Pike), as summarized by the Rules of Programming Style document. These additional rules apply:
Names: We encourage (but do not require) you to prefix each variable name with characters that indicate its type. For example, the prefix "c" might indicate that the variable is of type char, "i" might indicate int, "pc" might mean pointer to char, "ui" might mean unsigned int, etc.
Line lengths: Limit line lengths in your source code to 72 characters. Doing so allows us to print your work in two columns, thus saving paper.
Comments: Each source code file should begin with a comment that includes your name, the number of the assignment, and the name of the file.
Comments: Each function should begin with a comment that describes what the function does. The function comment should:
In short, a function's comment should describe the flow of data into and out of the function. For example, this is an appropriate way to comment the Str_getLength() function:
In file str.h:
...size_t Str_getLength(const char pcStr[]); /* Return the length of string pcStr. It is a checked runtime error for pcStr to be NULL. */...
In file strp.c:
...size_t Str_getLength(const char *pcStr) /* Return the length of string pcStr. It is a checked runtime error for pcStr to be NULL. */ { const char *pcStrEnd = pcStr; assert(pcStr != NULL); while (*pcStrEnd != '\0') pcStrEnd++; return (size_t)(pcStrEnd - pcStr); }...
Note that the comment explicitly states what the function returns, explicitly refers to the function's parameter (pcStr), and explicitly describes the function's checked runtime error.
C programmers sometimes use idioms that rely on the fact that the end-of-string character, the NULL pointer, and FALSE have the same representation. You may use those idioms. For example, you may define your Str_getLength() function like this:
size_t Str_getLength(const char pcStr[])
{
size_t uiLength = 0U;
assert(pcStr); /* Works because NULL and FALSE are identical. */
while (pcStr[uiLength]) /* Works because end-of-string and FALSE are identical. */
uiLength++;
return uiLength;
}
or like this:
size_t Str_getLength(const char *pcStr)
{
const char *pcStrEnd = pcStr;
assert(pcStr); /* Works because NULL and FALSE are identical. */
while (*pcStrEnd) /* Works because end-of-string and FALSE are identical. */
pcStrEnd++;
return (size_t)(pcStrEnd - pcStr);
}
But you are not required to use those idioms. In fact, we recommend that you avoid the use of idioms that adversely affect understandability.
The use of the "const" keyword within the Str_search() function is tricky, as this question/answer sequence indicates.
According to the man pages, the formal parameters of the strstr() function are of type const char*. That implies that the formal parameters of Str_search() also should be of type const char*. Why aren't they of type char*?
Suppose you were to define your Str_search() function like this:
char *Str_search(char *pc1, char *pc2) { ... }
Further suppose the client then calls Str_search() like this:
const char *pcString1 = "hello"; const char *pcString2 = "lo"; ... ... Str_search(pcString1, pcString2) ... ...
(Note that's a perfectly reasonable way to call the function.) In that case the compiler, noting that pcString1 is of type const char* and that pc1 is of type char*, would generate a warning on the function call. Thus pc1 (and pc2) should be of type const char*.
According to the man pages, the return type of strstr() is char*. That implies that the return type of Str_search() also should be of type char*. Why isn't the return type const char*?
Suppose you were to define Str_search() like this:
const char *Str_search(const char *pc1, const char *pc2) { ... }
Further suppose the client then calls Str_search() like this:
char *pcString1 = "hello"; char *pcString2 = "lo"; char *pc; ... pc = Str_search(pcString1, pcString2); ...
(Note that's a perfectly reasonable way to call the function.) In that case the compiler, noting that pc is of type char* and that the value returned by Str_search() is of type const char*, would generate a warning on the assignment statement. Thus the return type of Str_search() should be char* and should not be const char*.
Within the definition of Str_search(), I decided to define a local variable named pc that "points into" the first of the two given strings, as indicated by this code:
char *Str_search(const char *pc1, const char *pc2)
{
...
pc = pc1;
...
/* Increment pc so it points to the appropriate character. */
...
return pc;
}
If I define pc to be of type char*, then the assignment statement generates a warning. If I define pc to be of type const char*, then the return statement generates a warning. How can I resolve that problem?
Unfortunately, C provides no elegant solution. We recommend that you define pc to be of type const char* so the assignment statement is warningless. Then use a cast operator in the return statement:
return (char*)pc;
to explicitly inform the compiler to not generate a warning. C programmers refer to that solution as "casting away the constness" of the variable. Sadly, that inelegant technique often is unavoidable.