Consider the following code fragment:

char str[] = "bresenhams";
char *p = str + sizeof(str) - 8, ch = *++p;
printf("%c,%s", ch, str);

If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment's execution causes undefined behavior, write [for undefined behavior]. Otherwise, write the exact text printed to standard output stream by the code fragment.

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

Consider the following code fragment:

char str[] = "Mathematical";
char *p = str + 7, ch = (*p)--;
printf("%c,%s", ch, str);

If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment's execution causes undefined behavior, write [for undefined behavior]. Otherwise, write the exact text printed to standard output stream by the code fragment.

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

Consider the following code fragment:

char str[] = "UnCopyRightAbles";
char *p = str + 5, ch = (*p)++;
printf("%c,%s", ch, str);

If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment's execution causes undefined behavior, write [for undefined behavior]. Otherwise, write the exact text printed to standard output stream by the code fragment.

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

Write the exact text printed to standard output stream by the following code fragment. If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment generates undefined behavior, write [for undefined behavior].

enum { MAX_STR_LEN = 256 };
char str1[MAX_STR_LEN] = "Sunny", str2[MAX_STR_LEN] = "days";
if (str2 == str1) { // compare a character array to another character array
  fputs("alike", stdout);
} else {
  fputs("not alike", stdout);
}

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

Write the exact text printed to standard output stream by the following code fragment. If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment generates undefined behavior, write [for undefined behavior].

char name[4] = {'E','l','m','o'};
fputs(name, stdout);

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

A short note on function fgets

Function fgets reads lines from an input stream. The function takes 3 parameters:

• the base address of the buffer to store the read-in line
• the maximum number of characters to read from the file minus one, and
• a pointer to an input file stream

So the call:

fgets(buf, 81, infile);

says to read up to characters from input file stream infile and store these characters into an array whose address is specified by buf. The function will read less than  characters if it reaches the end of the file or if its reads a newline character first. In any case, fgets stores a null character immediately after the last character written to buf.

Since fgets takes an upper bound on the number of characters to read, it should be the function of choice especially if you're not sure how long the lines you're reading are. For example, fgets(buf, 81, stdin) will read up to characters from standard input stream even if there are more characters in the current line.

Finally, fgets will return its first parameter on success; otherwise the function will return NULL when it reaches the end of the file without reading any characters.

A short note on function fputs

Function fputs writes a line to a specified stream. That is, the call

fputs(buf, outfile);

writes the contents of array buf to output file stream outfile. Note that fputs does not append a newline character to the stream. Therefore, the statement

fputs(buf, stdout);

is equivalent to the statement

printf("%s", buf);

Question

Consider the execution of the following code fragment:

#define MAX_LEN (257)
char str[MAX_LEN];
fputs("Enter a sentence: ", stdout);
fgets(str, MAX_LEN, stdin);
fputs(str, stdout);

Suppose in response to the program's prompt, a user enters the text today is a good day through the keyboard [followed by the key]. Now, write the exact text written to the standard output stream by the program's final statement including any newline chars.

Write the exact value resulting from the evaluation of expression sizeof("").

Write the exact text printed to standard output stream by the code fragment. If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment generates undefined behavior, write [for undefined behavior].

enum { MAX_STR_LEN = 256 };
char str1[MAX_STR_LEN] = "Sunny", char str2[MAX_STR_LEN];
str2 = str1;
printf("%s", str2);

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.

Write the exact value resulting from the evaluation of expression sizeof("a").

Write the exact text printed to standard output stream by the following code fragment. If the code fragment cannot be compiled, write [for compile-time error]. If the code fragment generates undefined behavior, write [for undefined behavior].

enum { MAX_STR_LEN = 256 };
char str[MAX_STR_LEN];
str = "Sunny";
printf("%s", str);

Brief side-note on undefined behavior: The C standard says that statements such as c = (b = a + 2) - (a = 1); and c = (b = a + 2) - (a = 1); cause undefined behavior [because we don't know whether the left or right operand of operator - is evaluated first]. When a program ventures into the realm of undefined behavior, all bets are off. The program may behave differently when compiled with different compilers. But that's not the only thing that can happen. The program may not compile in the first place, if it compiles it may not run, and if it does run, it may crash, behave erratically, or produce meaningless results. In other words, undefined behavior should be avoided like the plague.