Write the exact value resulting from the evaluation of expression sizeof("representation"[5]).

Is the following declaration statement legal?

char str[] = "Redmond" " " "WA";

Given the following definition:

char str[] = "Sunny";

is the initializer "Sunny" a string literal?

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

A string literal or string constant is a sequence of zero or more characters enclosed in double quotes, as in "I am a string" or the empty string "".

The quotes are not part of the string, but serve only to delimit it. Other examples of string literals are:

"hello world"
"total expenditures: "
"C comments begin with \'/*\'.\n"

String literals can be concatenated at compile time. For example, the following two string literals:

"hello, " "world"

are equivalent to the string literal

"hello, world"

Technically, a string literal is an array of characters with the internal representation having a null character '\0' at the end. This means that the physical storage required for a string literal is one more than the number of characters written before the quotes. This also means that a string literal containing a single character is not the same as a character constant. The string literal "a" is an array of  char elements with the first char element having value 'a' and the second char element having null character '\0'. On the other hand, character constant 'a' has an integral value [in the ASCII character set] and is of type int.

Since a string literal is an array of characters, we can use the subscript operator to access individual characters in the array, as in expression "representation"[2] which evaluates to value 'p' of type char.

Now, write the exact value resulting from the evaluation of expression sizeof("representation").

Given the following declaration statements:

// Assume the 64-bit GCC compiler provides storage for array object a at address 1000
short a[] = { 3, 6, 2, 4, 7, 8 };
short *p1 = a + 1;
short *p5 = a + 5;

evaluate expression p1 = p5 - 3. If the expression cannot be compiled, write [for compile-time error]. If the expression generates undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the expression's evaluation.

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.

Given the following declaration statements:

// Assume the 64-bit GCC compiler provides storage for array object a at address 1000
short a[] = { 3, 6, 2, 4, 7, 8 };
short *p1 = a + 1, *p3 = a + 3, *p5 = a + 5;

evaluate expression p1 -= p5 - p3. If the expression cannot be compiled, write [for compile-time error]. If the expression generates undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the expression's evaluation.

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.

Given the following declaration statements:

// Assume the 64-bit GCC compiler provides storage for array object a at address 1000
short a[] = { 3, 6, 2, 4, 7, 8 };
short *p1 = a + 1, *p3 = a + 3, *p5 = a + 5;

evaluate expression p1 += p5 - p3. If the expression cannot be compiled, write [for compile-time error]. If the expression generates undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the expression's evaluation.

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.

Given the following declaration statements:

// Assume the 64-bit GCC compiler provides storage for array object a at address 1000
short a[] = { 3, 6, 2, 4, 7, 8 };
short *p1 = a + 1, *p5 = a + 5;

evaluate expression p5 - 2 - p1. If the expression cannot be compiled, write [for compile-time error]. If the expression generates undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the expression's evaluation.

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.

Given the following declaration statements:

// Assume the 64-bit GCC compiler provides storage for array object a at address 1000
short a[] = { 3, 6, 2, 4, 7, 8 };
short *p1 = a + 1, *p3 = a + 3, *p5 = a + 5;

evaluate expression p1 - p3 - p5. If the expression cannot be compiled, write [for compile-time error]. If the expression generates undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the expression's evaluation.

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.