Question 1

C#.NET — choose the valid ways to convert a Single (float) to a String.

Accepted Answer

Introduction / Context: Converting numeric types to strings is routine in C#.NET. The question presents several code snippets and asks which are valid for converting a Single (alias float) into a String. Given Data / Assumptions: Single f = 9.8f; then assign a string variable s. Snippets may include syntax from other languages or invalid casts. Concept / Approach: In C#, use Convert.ToString or the instance ToString() method. Direct casting from float to string is illegal, and VB-specific functions like CString or Clnt do not exist in C#. Step-by-Step Solution: Valid: s = Convert.ToString(f); → uses framework converter.Valid: s = f.ToString(); → instance method on value type.Invalid: (String)(f) → no direct cast defined.Invalid: Clnt and CString → VB-style; not C# identifiers. Verification / Alternative check: Try formatting: f.ToString("F2") for 2 decimal places, demonstrating rich formatting support. Why Other Options Are Wrong: They are either syntactically invalid in C# or rely on non-existent conversion helpers. Common Pitfalls: Assuming a C-style cast will work for disparate types like float to string. Final Answer: s = Convert.ToString(f); (also acceptable: s = f.ToString();)

Question 2

C#.NET strings — select the correct statement about strings.

Accepted Answer

Introduction / Context: This item focuses on core properties of C# strings: immutability, indexing, and representation. Given Data / Assumptions: We are evaluating stand-alone statements regarding strings. Concept / Approach: In C#, string is immutable and zero-indexed. You can create new strings via methods, but existing instances do not change in place. Step-by-Step Solution: Immutability: statements (a) and (b) are false; methods return new strings instead of modifying the original.Numeric text: (c) is false; any number can be represented as text (e.g., "123").Indexing: (d) is true — string indexer uses zero-based positions.Representation: (e) is false — strings are System.String, not System.Array, though you can get a char[] copy. Verification / Alternative check: Observe that s.Replace("a","b") leaves s unchanged and returns a new string. Why Other Options Are Wrong: They contradict immutability or conflate arrays with strings. Common Pitfalls: Assuming string behaves like a mutable character buffer; use StringBuilder for that. Final Answer: A String has a zero-based index.

Question 3

C#.NET strings — evaluate the output of: String s1 = "ALL MEN ARE CREATED EQUAL"; String s2; s2 = s1.Substring(12, 3); Console.WriteLine(s2);

Accepted Answer

Introduction / Context: This tests correct use of Substring(startIndex, length) with zero-based indexing. Given Data / Assumptions: s1 = "ALL MEN ARE CREATED EQUAL" startIndex = 12, length = 3 Concept / Approach: Substring takes characters starting at startIndex and returns exactly length characters. Indexes are zero-based and include spaces as characters. Step-by-Step Solution: Enumerate indices: 0 A, 1 L, 2 L, 3 space, 4 M, 5 E, 6 N, 7 space, 8 A, 9 R, 10 E, 11 space, 12 C, 13 R, 14 E, ...Starting at 12 for 3 characters → "C", "R", "E" → "CRE". Verification / Alternative check: Print s1[12], s1[13], s1[14] to confirm characters. Why Other Options Are Wrong: ARE or REA correspond to other ranges; CREATED is too long. Common Pitfalls: Off-by-one errors or forgetting spaces count toward indices. Final Answer: CRE

Question 4

C#.NET — Determine the correct output for the code: String s1 = "Kicit"; Console.Write(s1.IndexOf('c') + " "); Console.Write(s1.Length);

Accepted Answer

Introduction / Context: This program evaluates two string operations: finding the index of a character and retrieving the length of the string. It checks whether the learner understands zero-based indexing in C#.NET strings and how IndexOf works. Given Data / Assumptions: s1 = "Kicit" Method call: s1.IndexOf('c') Property: s1.Length Concept / Approach: Strings in C# are zero-based, meaning the first character is at index 0. IndexOf returns the index of the first occurrence of a given character or substring. Length returns the number of characters in the string. Step-by-Step Solution: Characters with indices: 0 → K, 1 → i, 2 → c, 3 → i, 4 → tIndexOf('c') = 2 because c appears at index 2.Length = 5 because there are five characters total.The program prints: "2 5". Verification / Alternative check: Test in a C# REPL or Visual Studio project confirms IndexOf('c') == 2 and Length == 5. Output matches expectation. Why Other Options Are Wrong: (a) and (c) suggest incorrect index or length. (d) assumes length 6, which is wrong. (e) assumes 7, which is also wrong. Common Pitfalls: Counting indices from 1 instead of 0 or mistaking Length as the last index rather than number of elements. Final Answer: 2 5

Question 5

C strings and the null terminator: what does this program print? #include #include int main() { static char s[] = "Hello!"; printf("%d ", *(s + strlen(s))); return 0; }

Accepted Answer

Introduction / Context: This question checks your knowledge of how strlen works and what lies at the first index past the last character in a C string. It emphasizes the importance of the null terminator '\0'. Given Data / Assumptions: s is "Hello!" which has 6 visible characters. strlen(s) returns the number of characters before the null terminator, so strlen(s) = 6. s is a proper C string with s[6] == '\0'. Concept / Approach: C strings end with a null byte, numeric value 0. The expression s + strlen(s) points exactly to that null byte. Dereferencing it with *(...) yields the char value 0, which then promotes to int when printed with %d. Step-by-Step Solution: Compute n = strlen(s) → 6.Pointer arithmetic: s + n points to s[6], the null terminator.Dereference *(s + n) → value is '\0', whose integer value is 0.printf("%d", 0) prints 0. Verification / Alternative check: Printing as a character with "%c" would not show a printable symbol because '\0' is non-printing. Using s[n-1] would print '!' with value 33 if printed as %d. Why Other Options Are Wrong: Numbers like 8, 16, or 33 correspond to other characters or guesses and are unrelated to the null byte here. “Error” is incorrect because the code is valid and well-defined. Common Pitfalls: Off-by-one errors around string ends; assuming strlen counts the terminator; mixing character codes with visible characters without confirming the exact index. Final Answer: 0

Question 6

Nested standard-library calls: what does this program print after strcat then strcpy? #include #include int main() { char str1[20] = "Hello", str2[20] = " World"; printf("%s ", strcpy(str2, strcat(str1, str2))); return 0; }

Accepted Answer

Introduction / Context: This question tests understanding of strcat and strcpy return values and side effects, plus buffer sizing. The order of nested calls matters because each returns a pointer that becomes the input to the next function. Given Data / Assumptions: str1 has capacity 20 and initial contents "Hello". str2 has capacity 20 and initial contents " World". strcat(dest, src) appends src to dest and returns dest; strcpy(dest, src) copies src into dest and returns dest. Concept / Approach: Evaluate from inside: strcat(str1, str2) appends " World" to "Hello" producing "Hello World" in str1 and returns str1. Then strcpy(str2, returned_pointer) copies "Hello World" into str2 and returns str2. printf prints the resulting str2. Step-by-Step Solution: strcat(str1, str2) → str1 becomes "Hello World", function returns str1.strcpy(str2, ) → str2 becomes "Hello World".printf prints str2, so output is "Hello World". Verification / Alternative check: After execution, both str1 and str2 contain "Hello World". Buffers are sufficiently large, so there is no overflow. Why Other Options Are Wrong: "Hello" ignores the concatenation. "World" or "WorldHello" misunderstand the direction of copying and concatenation. Behavior is well-defined given buffer sizes. Common Pitfalls: Forgetting that strcat modifies the first argument; misremembering return values of these functions; insufficient buffer space can cause undefined behavior in other contexts. Final Answer: Hello World

Question 7

Comparing two distinct C arrays of identical contents: what does this program print?  #include<stdio.h>  int main() { char str1[] = "Hello"; char str2[] = "Hello"; if (str1 == str2) printf("Equal "); else printf("Unequal "); return 0; }

Accepted Answer

Introduction / Context: In C, arrays are not directly comparable by value with ==. When used in expressions, array names decay to pointers to their first elements. This program compares the addresses of two separate arrays, not their string contents. Given Data / Assumptions: Two separate arrays: str1 and str2, each initialized with "Hello". The expression str1 == str2 compares the addresses of the first elements of each array. They are distinct objects in memory. Concept / Approach: Since str1 and str2 denote different storage, their addresses are different, so pointer equality is false. Value comparison of strings requires strcmp (or memcmp for raw bytes) rather than ==. Therefore the else branch executes and prints "Unequal". Step-by-Step Solution: str1 and str2 each hold "Hello" and terminate with '\0'.When compared with ==, they decay to pointers (char*).The pointers do not reference the same memory location, so comparison is false.Program prints "Unequal". Verification / Alternative check: Using if (strcmp(str1, str2) == 0) would print "Equal". Or assign one pointer to reference the other’s buffer (char *p = str1; char *q = str1;), then p == q would be true. Why Other Options Are Wrong: “Equal” mistakes value equality for pointer equality. “Error” is incorrect; code compiles. The “depends on compiler” option is wrong; the objects are distinct by definition. Common Pitfalls: Confusing array names with pointers; relying on == for string content comparison instead of strcmp. Final Answer: Unequal

Question 8

In C, what will be the exact output of this program (note the embedded nulls and how strlen works)? #include #include int main() { char str[] = "India\0\CURIOUSTAB\0"; printf("%d ", strlen(str)); return 0; } Choose the corre…

Accepted Answer

Introduction / Context: This question tests understanding of C strings, the effect of the null terminator (the byte with value 0), and the standard library function strlen. In C, strings are sequences of characters terminated by a null byte, and library functions stop at the first null byte regardless of any additional characters that may exist afterward in the same array. Given Data / Assumptions: The character array literal is initialized as "India\0\CURIOUSTAB\0". In C string handling, the first null byte marks the end of the string for functions like strlen and printf with %s. strlen counts characters up to but not including the first null terminator. We assume a typical hosted C implementation following the standard rules for string functions. Concept / Approach: strlen(s) returns the number of characters before the first 0 byte in s. Any bytes after the first 0 are ignored for length purposes, even if they are part of the same array. Thus, only the leading segment prior to the first null contributes to the length. Step-by-Step Solution: The array begins with the bytes for the letters I n d i a.Immediately after these 5 letters, there is a null terminator (\0).strlen examines bytes starting at str[0] and stops as soon as it encounters the first 0 byte.Therefore, strlen("India\0...") returns 5.The trailing characters like C U R I O U S T A B and any later nulls are ignored by strlen. Verification / Alternative check: Printing with printf("%s", str) would output only "India" for the same reason (stopping at the first null). Using sizeof(str) would count the entire array length including all bytes and nulls, which is different from strlen. Why Other Options Are Wrong: 10 / 11 / 6: These treat the post-null bytes as part of the length, which strlen never does.None of the above: Incorrect because 5 is valid and exact. Common Pitfalls: Mistaking the array's allocated size for the string length; assuming embedded nulls are ignored; thinking escape sequences like \C change length (they do not extend the first segment before the null). Final Answer: 5

Question 9

In C, what does this program print with %s given embedded null bytes inside the array literal? #include #include int main() { char str[] = "India\0\CURIOUSTAB\0"; printf("%s ", str); return 0; } Select the exact output.

Accepted Answer

Introduction / Context: This examines how printf with the %s format specifier handles C strings that contain embedded null bytes. In C, a string is terminated by the first null byte; any content after the first 0 byte is not part of the printable string for %s. Given Data / Assumptions: An array initialized with "India\0\CURIOUSTAB\0". printf("%s", str) prints characters until the first null byte. The character encoding is ASCII-like so letters display ordinarily. Concept / Approach: %s expects a pointer to a null-terminated byte sequence. The library reads characters sequentially, stopping at the first 0 byte. Thus, any bytes stored after the first null are ignored for printing via %s unless you print them separately by pointer arithmetic. Step-by-Step Solution: The sequence at the array start is I n d i a followed by a null byte.printf("%s", str) reads characters until it reaches that null terminator.Therefore, only "India" appears on the output line. Verification / Alternative check: If one printed &str[6] (i.e., a pointer into the array beyond the first null) and if the next segment were properly terminated, you could print "CURIOUSTAB". But with %s on str itself, output is just the first segment. Why Other Options Are Wrong: CURIOUSTAB / India CURIOUSTAB / India\0CURIOUSTAB: They incorrectly assume that %s ignores or prints through the first null.None of the above: Incorrect because the program clearly prints "India". Common Pitfalls: Confusing array storage with C-string semantics; forgetting that %s requires a single contiguous, null-terminated string starting at the given pointer. Final Answer: India

Question 10

In C, consider strcmp on two user-entered strings using gets (unsafe). What output should you expect from this program and why can it vary? #include #include int main() { char str1[5], str2[5]; int i; gets(str1); gets(str2);…

Accepted Answer

Introduction / Context: This question probes how strcmp reports lexical ordering and why its numeric return value is implementation-dependent. It also highlights the dangers of gets, which can overflow buffers and is removed from modern C. The essential learning: strcmp returns a negative, zero, or positive integer whose magnitude is not standardized. Given Data / Assumptions: Two small buffers of size 5 are filled with user input via gets (unsafe). strcmp returns <0, 0, or >0 depending on lexicographic order. The exact negative or positive value is not specified by the C standard. Inputs are unknown at question time, so the result varies. Concept / Approach: strcmp(a, b) compares the first differing bytes as unsigned char. It returns an integer less than, equal to, or greater than zero. Only the sign matters. Therefore you must not assume -1, 0, or +1 specifically; any negative or positive value can be returned based on character code differences. Step-by-Step Solution: User types some line for str1 and str2.strcmp computes the first position where they differ or reaches the terminator.It returns an int whose sign indicates ordering: <0 if str1 < str2, 0 if equal, >0 if str1 > str2.Hence, the exact integer printed is unpredictable beforehand and depends on inputs and character codes. Verification / Alternative check: Try various pairs (e.g., "cat" vs "car") across platforms; you may see different negative magnitudes, though the sign is consistent. Also note that using gets invites buffer overflow; safer alternatives are fgets or scanf with width limits. Why Other Options Are Wrong: 0 / -1 / Always positive: These assert specific results independent of inputs or assume a fixed magnitude.Error: The code compiles; runtime errors happen only if overflow occurs, not guaranteed by the snippet itself. Common Pitfalls: Assuming strcmp returns only -1, 0, +1; using gets; neglecting buffer sizes and missing null terminators. Final Answer: Unpredictable integer value

Question 11

C printf with extra arguments: what will this program print when the format string contains no conversion specifiers?  #include<stdio.h>  int main() {  printf("India", "CURIOUSTAB ");  return 0; }  Select the exact output that appears.

Accepted Answer

Introduction / Context: Here we test printf behavior when the format string has no conversion specifiers and an extra argument is passed. Understanding varargs and format processing helps prevent misuse and vulnerabilities. Given Data / Assumptions: The call is printf("India", "CURIOUSTAB"). "India" is a literal with no % placeholders. printf prints exactly the format string, interpreting % directives if any. Extra arguments with no matching conversion are ignored by the runtime formatting logic. Concept / Approach: printf processes its first argument as a format string. If there are no conversion specifiers, it simply writes the format text. Although supplying extra arguments is undefined by strict standards discussions, practical implementations will not consume them because no % directives appear. Step-by-Step Solution: Format string is "India".No % specifiers are present to consume subsequent arguments.printf therefore writes "India" to stdout. Verification / Alternative check: Compile and run; you see "India" (without a newline). Adding "%s" to the format, as in printf("%s", "CURIOUSTAB"), would print the passed string. Why Other Options Are Wrong: "India CURIOUSTAB" / "CURIOUSTAB": would require format placeholders.Error / No output: the code compiles and prints the literal. Common Pitfalls: Thinking printf automatically prints all subsequent arguments; forgetting to include a newline or appropriate format specifiers. Final Answer: India

Question 12

In C, swapping two pointers to string literals inside an array: what exactly does this program print?  #include<stdio.h>  int main() {  char *names[] = { "Suresh", "Siva", "Sona", "Baiju", "Ritu"};  int i;  char *t;  t = names[3];  names[3] = names[…

Accepted Answer

Introduction / Context: This question checks pointer swapping in an array of pointers to string literals. Instead of moving characters, the code swaps pointers, which is efficient and changes the printed order of names without copying strings. Given Data / Assumptions: names is an array of 5 pointers to constant string literals. Indices: names[0]=Suresh, [1]=Siva, [2]=Sona, [3]=Baiju, [4]=Ritu. We swap names[3] and names[4] using a temporary pointer t. The loop prints each name followed by a comma, in index order 0..4. Concept / Approach: Swapping pointers changes which strings are referenced at positions 3 and 4. Pointer swapping does not modify the literals themselves; it only reassigns which address is stored in each array slot. Step-by-Step Solution: Before swap: [Suresh, Siva, Sona, Baiju, Ritu].t = names[3] makes t point to "Baiju".names[3] = names[4] assigns "Ritu" to index 3.names[4] = t assigns "Baiju" to index 4.Printing 0..4 after swap yields: Suresh, Siva, Sona, Ritu, Baiju, Verification / Alternative check: Add printf calls before and after the swap to confirm index contents changed as expected. Since these are literals, no memory copying occurs. Why Other Options Are Wrong: Original order (option a) ignores the swap.The other permutations do not reflect swapping exactly the last two entries. Common Pitfalls: Confusing character arrays with pointer arrays; attempting to free string literals; thinking swap copies data rather than pointer values. Final Answer: Suresh, Siva, Sona, Ritu, Baiju

Question 13

Indexing tricks and side effects in C: determine the precise characters printed by this code involving pre/post increment and the i[s] notation.  #include<stdio.h>  int main() {  static char s[25] = "The cocaine man";  int i = 0;  char ch;  ch = s[+…

Accepted Answer

Introduction / Context: This problem explores array indexing equivalence, pre/post-increment behavior, and modification of characters through lvalues. The expression i[s] is the same as s[i]; both rely on pointer arithmetic. Understanding evaluation order and side effects is essential to predict the output. Given Data / Assumptions: s = "The cocaine man" with indices: T(0), h(1), e(2), space(3), c(4), o(5), c(6), a(7), i(8), n(9), e(10), space(11), m(12), a(13), n(14). i starts at 0. Pre-increment ++i updates i before indexing; post-increment i++ uses the current value, then increments. Expression i[s] equals s[i]. Concept / Approach: Track i carefully and know what character each operation reads or writes. The last operation ++i[s] increments the stored character at position i and yields the incremented character, altering the array content. Step-by-Step Solution: ch = s[++i]; i becomes 1; s[1] = 'h' → prints h.ch = s[i++]; uses i = 1 then increments to 2; s[1] = 'h' → prints h.ch = i++[s]; same as s[i++]; uses i = 2 then increments to 3; s[2] = 'e' → prints e.ch = ++i[s]; i is 3; i[s] is s[3] (space). ++ applied to the character increments space (ASCII 32) to '!' (ASCII 33), stores back, and yields '!' → prints !. Verification / Alternative check: Insert debugging prints of i and character codes; you will see i evolve as 1, 2, 3 and the final modification at index 3. After execution, s becomes "The!cocaine man" due to the mutated space. Why Other Options Are Wrong: 'he c', 'The c', 'Hhec': do not match the exact sequence of characters and increments produced by the operations. Common Pitfalls: Thinking i[s] is different from s[i]; forgetting that ++ on a char lvalue changes the stored character; mixing up pre vs post increment. Final Answer: hhe!

Question 14

Recursive I/O with getchar and printing on unwinding: if the user inputs the characters a, b, c followed by Enter, what will this program print?  #include<stdio.h>  int main() {  void fun();  fun();  printf(" ");  return 0; } void fun() {  char c;  …

Accepted Answer

Introduction / Context: This tests understanding of recursion order and when output happens relative to input. The function fun reads one character at a time until a newline, then prints characters after the recursive calls return, producing reverse order. Given Data / Assumptions: User types: a, then b, then c, then Enter (newline). The recursion continues while the read character is not newline. Printing occurs after the recursive call returns, during the unwinding phase. printf in main adds a trailing newline at the end. Concept / Approach: With post-recursive printing, the deepest call corresponds to the last non-newline character read. As the stack unwinds, characters are printed in last-in-first-out order, i.e., reversed. Step-by-Step Solution: User enters 'a': c = 'a' (not newline) → recurse.Then 'b': c = 'b' → recurse.Then 'c': c = 'c' → recurse.Then newline: c = '' → no further recursion; print '' as the base case prints the newline character (it prints at the end, but here the code prints c even when it is newline, yielding a line break).Unwinding: prints 'c', then 'b', then 'a' in that order; main prints another newline. Verification / Alternative check: Run the code and type abc followed by Enter. You will see cba printed (with a newline because both the base case prints newline and main prints a newline). Why Other Options Are Wrong: 'abc abc' / 'bca': These assume forward-order or mixed-order printing.Infinite loop: Termination occurs upon reading newline. Common Pitfalls: Expecting pre-recursive printing; overlooking that printf("%c", c) is executed after recursive call returns; forgetting that the newline character will also be printed by this code. Final Answer: cba

Question 15

String reversal using indexing: what does this C program output after reading a line with gets and then printing characters in reverse order? #include #include int main() { char sentence[80]; int i; printf("Enter a line of te…

Accepted Answer

Introduction / Context: This question verifies knowledge of iterating backwards through a C string using strlen and array indexing. The code demonstrates reversal by printing characters from the last index down to zero. Given Data / Assumptions: sentence has space for up to 79 visible characters plus the null terminator. gets is used (unsafe) to read a line; it excludes the newline and appends '\0' at the end. strlen(sentence) returns the number of characters before the null terminator. putchar writes single characters in the loop. Concept / Approach: The loop initializes i to strlen(sentence) - 1 (the last valid character index) and decrements down to 0 inclusive. This prints the string in reverse order. Step-by-Step Solution: User enters text, e.g., "hello".strlen("hello") = 5, so start i = 4.putchar(sentence[4]) prints 'o', then i becomes 3 → prints 'l', then 2 → 'l', then 1 → 'e', then 0 → 'h'.Loop ends after i becomes -1, and the output is the reverse of the input. Verification / Alternative check: Compare with using strrev (non-standard) or manual two-pointer reversal in a buffer; all produce the reversed text. Why Other Options Are Wrong: Same order: would require forward iteration.Half printed: the loop clearly covers all indices down to 0.None of above / does not compile: the code compiles; logical behavior is reversal. Common Pitfalls: Using gets (unsafe, buffer overflow risk); forgetting that strlen excludes the null terminator; off-by-one errors in start or end indices. Final Answer: The sentence will get printed in reverse order

Question 16

Array indexing into a string literal in C: what character does this code print? #include #include int main() { printf("%c ", "abcdefgh"[4]); return 0; } Pick the exact character output.

Accepted Answer

Introduction / Context: This item checks understanding that string literals can be indexed like arrays of char. The expression "abcdefgh"[n] yields the character at zero-based index n of the literal. Given Data / Assumptions: Literal is "abcdefgh". Index used is 4 (zero-based). printf with %c prints a single character. Concept / Approach: In C, a string literal has type array of const char (or char in older C), and it can be indexed before array-to-pointer decay in expressions. Zero-based indexing means position 0 is 'a', 1 is 'b', 2 is 'c', 3 is 'd', 4 is 'e'. Step-by-Step Solution: Compute index 4 → the 5th character in "abcdefgh".Character at index 4 is 'e'.printf("%c", ... ) prints that character followed by newline. Verification / Alternative check: You can confirm by printing the entire literal and manually counting or by looping indices 0..7 and printing each index and character. Why Other Options Are Wrong: 'd': off by one (index 3).'abcdefgh': would require %s and a pointer to the first character.Error / None of the above: The code is valid and the correct character is 'e'. Common Pitfalls: Forgetting zero-based indexing; confusing %c and %s; assuming literals cannot be indexed. Final Answer: e

Question 17

Pointer types and %s in printf: what happens when you pass &str + 2 (a pointer to beyond the array) to %s?  #include<stdio.h>  int main() {  char str[25] = "CuriousTab";  printf("%s ", &str + 2);  return 0; }  Select the most accurate outcome.

Accepted Answer

Introduction / Context: This question highlights undefined behavior from passing an incorrect pointer type to printf with %s. The %s specifier expects a char* that points to a valid, null-terminated byte string. Supplying &str + 2 (type char ()[25] advanced by two arrays) is not a valid char pointer to a string. Given Data / Assumptions: str is an array of 25 chars initialized to "CuriousTab". &str has type char ()[25], a pointer to the entire array object. &str + 2 points two arrays past the object, i.e., far beyond valid storage. printf("%s", ...) expects a pointer of type char to a readable null-terminated sequence. Concept / Approach: When calling variadic functions, the argument types must match the format string. Here they do not. The value passed is a pointer-to-array (after arithmetic) rather than a char*. As a result, behavior is undefined: the program may crash, print garbage, or appear to print some bytes coincidentally. Step-by-Step Solution: Take address of array: &str → char ()[25].Add 2: &str + 2 → points beyond the valid array object.printf expects char: treats the mismatched pointer as if it were a char*.Reading memory at that bogus address yields undefined behavior (often garbage output or a fault). Verification / Alternative check: Correct usage would be printf("%s", str); or printf("%s", &str[0]); both produce "CuriousTab". Using &str + 2 is invalid regardless of platform. Why Other Options Are Wrong: Error / No output: The code typically compiles; runtime behavior is not predictably an error or silence."diaCURIOUSTAB": a specific string cannot be guaranteed; undefined behavior has no reliable outcome.Reliably prints "CuriousTab": only true with the correct pointer, not with &str + 2. Common Pitfalls: Confusing char* with char (*)[N]; doing pointer arithmetic on &str; forgetting that varargs require exact matching types for format specifiers. Final Answer: Garbage value

Question 18

C strings and strcat on string literals (Turbo C, 16-bit DOS): what will the following program print or do? #include #include int main() { char *str1 = 'India'; char *str2 = 'CURIOUSTAB'; char *str3; str3 = strcat(str1, str2…

Accepted Answer

Introduction / Context: This question checks your understanding of C string storage, mutability of string literals, and the behavior of strcat when given an invalid destination. We are asked about the observable outcome under a classic Turbo C (16-bit DOS) environment, which stores string literals in read-only segments or otherwise non-writable memory. Given Data / Assumptions: str1 and str2 are pointers to string literals ('India' and 'CURIOUSTAB'). strcat(dest, src) writes into dest’s buffer, appending src and the terminating '\0'. String literals are not modifiable; attempting to write to them produces undefined behavior (often a run-time crash or immediate error). Concept / Approach: strcat requires dest to point to a writable array with enough free space to hold the concatenation. Here, dest is str1, which points to a literal. Writing into a literal violates the C standard’s constraint and results in undefined behavior. Historically, on Turbo C and similar compilers, this typically causes an error or crash rather than clean output. Step-by-Step Solution: Identify dest: dest == str1 → points to a literal → not writable.strcat will try to find '\0' at the end of 'India' and copy bytes from 'CURIOUSTAB' into the memory where 'India' resides.This write into read-only storage triggers undefined behavior → practically an error/crash. Verification / Alternative check: Replace str1 with a char array of sufficient size (e.g., char str1[32] = 'India';). Then strcat succeeds and prints 'IndiaCURIOUSTAB IndiaCURIOUSTAB'. The failure only occurs when dest is a literal. Why Other Options Are Wrong: CuriousTab India / CuriousTab CuriousTab / India India / India CURIOUSTAB: All assume a successful, defined concatenation. That would require a writable array as destination, which we do not have here. Common Pitfalls: Treating 'char *p = 'text';' as if it were a writable array; forgetting that strcat needs adequate writable space in the destination. Final Answer: Error.

Question 19

C printf return value and empty strings: what does this program print?  #include<stdio.h>  int main() {  int i;  char a[] = '\0'; // empty C string  if (printf('%s', a))  printf('The string is not empty ');  else  printf('The string is empty ');  re…

Accepted Answer

Introduction / Context: This item tests knowledge of printf’s return value and behavior with empty strings. printf returns the number of characters printed. When passed an empty string, it prints nothing and returns 0, which is crucial for the if condition in this code. Given Data / Assumptions: a is initialized to a single '\0', so it is an empty, valid C string. printf('%s', a) prints characters until '\0'; here, it prints zero characters. In C, zero in a conditional is false; nonzero is true. Concept / Approach: Evaluating the if condition requires understanding that printf returns the count of printed characters. Printing an empty string prints nothing and returns 0, so the else branch executes. Step-by-Step Solution: Compute printf('%s', a): produces no output and returns 0.if (0) is false → execute the else branch.The program prints 'The string is empty' followed by a newline. Verification / Alternative check: Change a to 'X'; then printf prints 1 character, returns 1, and the if branch prints 'The string is not empty'. Why Other Options Are Wrong: 'The string is not empty': would require printf to return nonzero.'No output' or '0': the program always prints one of the messages.Compilation error: code is valid. Common Pitfalls: Assuming printf returns true when the call succeeds regardless of printed length; forgetting that empty strings are valid but print nothing. Final Answer: The string is empty.

Question 20

Addresses of string literals and %s printing: given that the memory address of the literal 'Hello1' is 1022 (Turbo C, 16-bit DOS), what will this print?  #include<stdio.h>  int main() {  printf('%u %s ', &'Hello1', &'Hello2');  return 0; }

Accepted Answer

Introduction / Context: This question examines pointer types with string literals, how the unary & operator changes the type, and how printf interprets arguments for %u and %s. It also assumes a specific address (1022) for the literal 'Hello1' to make the numeric output deterministic. Given Data / Assumptions: &'Hello1' yields a pointer to the entire array object of the literal (type char ()[7]), whose value as an address equals the start address of the first character. &'Hello2' similarly yields a pointer to the array for 'Hello2'. printf with %u expects an unsigned int; the pointer is passed and converted as an integer value on this legacy platform. %s expects a char, and &'Hello2' points to the same start address as a char*, so it prints 'Hello2'. Concept / Approach: Although the pointer types are not char*, the numeric value of &'Hello1' prints as the base address. For %s, &'Hello2' is treated as the base address of the literal string. On many older compilers, this prints correctly despite the subtle type mismatch (on modern compilers, you would cast explicitly). Step-by-Step Solution: %u with &'Hello1' → prints its address → 1022 (as given).%s with &'Hello2' → prints the characters from that base address → 'Hello2'. Verification / Alternative check: Replacing &'Hello2' with 'Hello2' (which decays to char*) still prints 'Hello2'. Both point to the same base address. Why Other Options Are Wrong: 'Hello1 1022' or 'Hello1 Hello2': would require using %s with 'Hello1' and not printing the numeric address.'1022 1022': incorrectly assumes both conversions produce numeric printing.'Error': legacy compilers typically accept this; behavior shown is the intended trick. Common Pitfalls: Confusing &'literal' with the decayed char* of a literal; assuming %s requires exactly char* and not recognizing platform permissiveness in old toolchains. Final Answer: 1022 Hello2.

Strings Questions