Consider the following code fragment:

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

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:

// function strlen is declared in <string.h>
char str[] = "DigiPen", *p;
for (p = str+strlen(str)-1; p >= str; --p) {
  ++*p;
}
fputs(str, stdout);

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[] = "CapeOfGoodHope", *p = 5+str;
while (p >= str) {
  ++*p;
  --p;
}
fputs(str, stdout);

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:

// assume the 64-bit GCC compiler assigns storage for variable bart at address 0x0100
int bart, *p = &bart;
for (bart = 0; bart < 4; ++bart) {
  printf("%p%s", (void*)(p+bart), (bart==3)?"":",");
}

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 involving -bit hexadecimal addresses 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.

Given the following function definition:

void mystery(int *a, int s) {
  int *b = a + s;
  while (++a != b) {
    *a += *(a - 1);
  }
}

consider the following code fragment:

int g[] = { 1, 2, 3, 4, 5, 6 }, *b = g;
int *p = g + sizeof(g)/sizeof(g[0]);
mystery(g, 3);
mystery(g + 2, 3);
while (b != p) {
  printf("%d ", *b++);
}

If the above code fragment cannot be compiled, write [for compile-time error]. If the code fragment causes undefined behavior, write [for undefined behavior]. Otherwise, write the exact value resulting from the code fragment's execution.

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 function definition:

int mystery(char const *src) {
  char const *pc = src;
  while (*src) src++;
  return src-pc;
}

evaluate expression mystery("subdermatoglyphic"). 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.

Consider the following code fragment:

char str[] = "ComputerGraphics";
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.

Consider the following code fragment:

char str[] = "DataStructures";
char *p = str + sizeof(str) - 2, 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[] = "GameDesigner";
char *p = str + sizeof(str) - 6, ch = *p--;
printf("%c,%s", ch, p);

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[] = "Multidimensional";
char *p = str + sizeof(str) - 1, 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.