Question 1

C scanf formatting: Given float a; and double b;, which scanf statement uses the correct conversion specifiers to read both values from input?

Accepted Answer

Introduction / Context:Correct conversion specifiers are essential when using scanf in C to avoid undefined behavior and corrupted inputs. In particular, float and double have different specifiers in scanf because arguments are not promoted the same way at input time as they are at output time with printf.Given Data / Assumptions:Variables are declared as float a; and double b;.We must read both in one scanf call.Standard C conversion specifiers apply.Concept / Approach:For scanf, use %f to read into a float* and %lf to read into a double*.%Lf is used for long double* with scanf.Although printf promotes float to double, scanf requires exact matching of pointed-to types.Step-by-Step Solution:Match a (float) → %f.Match b (double) → %lf.Therefore, the correct call is scanf("%f %lf", &a, &b);Verification / Alternative check:Attempting scanf("%f %f", &a, &b) misreads b because %f expects float*, not double*.Why Other Options Are Wrong:"%f %f": second %f does not match a double*."%Lf %Lf": %Lf expects long double*, not float* or double*."%f %Lf": first is correct for a; second expects long double* but b is double.Common Pitfalls:Confusing printf and scanf specifiers; they are not symmetric.Forgetting address-of operators (&) when passing variables to scanf.Final Answer:scanf("%f %lf", &a, &b);

Question 2

Safe line input in C: Between fgets() and gets(), which function is considered safe for reading a line of text (and why)?

Accepted Answer

Introduction / Context:Reading entire lines including spaces is a common need in C. Historically, gets was used, but it became notorious for buffer overflow vulnerabilities and has been removed from the C standard. Knowing the safe alternative is essential for writing robust, secure C programs.Given Data / Assumptions:We need to read a whole line that may contain spaces.We want a function that prevents buffer overflows by respecting buffer size.Portable, standard C behavior is desired.Concept / Approach:fgets(buffer, size, stream) reads at most size-1 characters and always terminates with a null byte if any characters are read, preventing overflows.gets reads until newline with no size limit; it cannot prevent writing past the end of the buffer.Some libraries offer getline or gets_s, but these are not universally portable in the same way as fgets.Step-by-Step Solution:Specify the buffer and its size → call fgets(buf, sizeof buf, stdin).On success, fgets stores the line including the trailing newline (unless the line exceeded the buffer or EOF occurred).Thus, the safe choice is fgets because it respects buffer boundaries.Verification / Alternative check:Security guidelines and modern compilers warn against gets; many toolchains remove it entirely. Compiling code using gets often fails.Why Other Options Are Wrong:gets(): Dangerous and removed from the standard; it cannot limit input length.getline(): Useful but POSIX, not ISO C; availability varies.gets_s(): Bounds-checked but not portable across all environments; not ISO C90/C99.Common Pitfalls:Forgetting that fgets keeps the trailing newline; trim it if needed.Passing the wrong size to fgets (must be the buffer's capacity).Final Answer:fgets()

Question 3

C printf formatting: With float a = 3.14; and double b = 3.14;, which printf statement uses correct specifiers to print both values?

Accepted Answer

Introduction / Context:Unlike scanf, printf receives its floating arguments after default promotions, so both float and double are passed as double. Still, choosing correct format specifiers avoids undefined behavior and documents intent clearly when printing mixed floating types.Given Data / Assumptions:a is declared float and b is declared double.We must print both in one call.Standard C printf format rules apply.Concept / Approach:printf expects a double for %f. A float argument is promoted to double, so %f prints both float and double values correctly.Many modern C standards accept %lf as a synonym for %f in printf; it is commonly treated the same as %f for printing a double.%Lf is reserved for long double; using it with float or double is incorrect.Step-by-Step Solution:Choose %f for the first value (a), which is promoted to double.Choose %lf (or %f) for the second value (b), which is a double.Therefore, printf("%f %lf", a, b); correctly prints both values.Verification / Alternative check:Testing with typical compilers shows identical output for %f and %lf in printf, while %Lf requires a long double argument.Why Other Options Are Wrong:"%Lf %f" and "%Lf %Lf": Incorrect because %Lf expects long double arguments."%f %Lf": Second specifier mismatches a double.Common Pitfalls:Confusing scanf and printf specifiers; scanf needs %lf for double input, while printf uses %f to print a double.Using %Lf without passing a long double leads to undefined behavior.Final Answer:printf("%f %lf", a, b);

Question 4

Behavior of fgets with Windows newlines: If a file contains the line "I am a boy\r ", what exact byte sequence will the char array str contain after calling fgets(str, size, fp)?

Accepted Answer

Introduction / Context:On Windows, text files commonly use CRLF line endings, represented as carriage return followed by newline (\r). Understanding how fgets handles these characters is key to correctly parsing input and trimming line endings for cross-platform applications.Given Data / Assumptions:The file contains the exact byte sequence for the line: letters plus \r before end of line.fgets reads up to and including the first , or until the buffer limit or EOF.There is sufficient buffer space to hold the entire line and terminator.Concept / Approach:fgets copies characters from the stream into the buffer until it either copies a , reaches size-1, or hits EOF.Whatever precedes (including a preceding \r) is also copied verbatim.After copying, fgets appends a null terminator \0.Step-by-Step Solution:Input stream bytes → 'I am a boy\r'.fgets copies bytes until and including , so both \r and end up in the buffer.fgets appends \0, yielding 'I am a boy\r\0' in memory.Verification / Alternative check:Printing with debugging or inspecting byte values shows 0x0D (\r), 0x0A (), followed by 0x00.Why Other Options Are Wrong:"I am a boy\r\0": Would imply fgets stops at \r, which it does not; it stops after copying ."I am a boy\0": Ignores the presence of \r in the file."I am a boy": Omits both line breaks and the terminator, which is incorrect for fgets.Common Pitfalls:Assuming fgets strips line endings; it keeps the if present and any preceding \r.For cross-platform trimming, explicitly remove trailing \r and as needed.Final Answer:"I am a boy\r\0"

Question 5

C file I/O API correctness: In the given program with three opened files, what happens when calling fclose(fp, fs, ft);?

Accepted Answer

Introduction / Context:Knowing the exact function signatures in the C standard library prevents subtle API misuse. The fclose function is designed to close a single stream at a time. Passing multiple arguments violates its prototype and leads to a compile-time error, which is important when managing several files in one function.Given Data / Assumptions:Three FILE* streams are successfully opened: fp, fs, and ft.The code calls fclose(fp, fs, ft); with three arguments.Standard C header is used.Concept / Approach:The prototype is int fclose(FILE stream); It accepts exactly one FILE.To close multiple files, invoke fclose separately for each pointer.Compilers type-check function calls and will reject calls with the wrong number or types of arguments.Step-by-Step Solution:Compare the call fclose(fp, fs, ft) with the prototype fclose(FILE*).Since three arguments are supplied instead of one, this is a mismatched call.Therefore, the result is a compile-time error, not the closing of any files.Verification / Alternative check:Correct usage should be: fclose(fp); fclose(fs); fclose(ft); Each call closes a single stream and returns 0 on success.Why Other Options Are Wrong:Listing any subset of files as closed implies fclose can take multiple pointers, which it cannot.Suggesting only "A.C" closes is arbitrary and still contradicts the function prototype.Common Pitfalls:Attempting to pass multiple resources to a single-argument API; instead, loop over the list and close individually.Ignoring fclose return values; always check for errors when closing streams.Final Answer:Error in fclose()

Question 6

Meaning of mode string in fopen: In the call fp = fopen("source.txt", "rb"); what does the mode "rb" instruct the C library to do?

Accepted Answer

Introduction / Context:The fopen mode string controls how a file is opened—text vs binary, reading vs writing, appending, and whether a new file is created or an existing one is truncated. Choosing the correct mode avoids data loss and platform-specific newline translations.Given Data / Assumptions:Call shown: fopen("source.txt", "rb").Standard C fopen modes apply.We aim to interpret the two-character mode "rb".Concept / Approach:"r" means open existing file for reading."b" means binary mode (no text translations such as CRLF to LF on Windows).To read and write, modes like "rb+" or "r+b" are used; to create/truncate for writing, use "w" variants.Step-by-Step Solution:Parse "r" → open for reading only.Parse "b" → open in binary mode (no newline conversion).Therefore, "rb" means open in binary mode for reading.Verification / Alternative check:If the intent were read/write, "rb+" would be required; if write/truncate, "wb" would be used.Why Other Options Are Wrong:Binary read/write: Requires "+" in the mode.Create for read/write: That is "wb+" or "w+b", not "rb".None of above: Incorrect because option A is accurate.Common Pitfalls:Opening text files in text mode on Windows and being surprised by newline translation; use "b" for binary data.Forgetting that "r" fails if the file does not exist.Final Answer:open "source.txt" in binary mode for reading

Question 7

Understanding fileno: In the program that opens "DUMMY.C" for writing and assigns t = fileno(fp);, what does t represent?

Accepted Answer

Introduction / Context:Standard I/O in C provides buffered FILE* streams, while lower-level system calls use integer file descriptors (often called handles on some platforms). The fileno function bridges these layers by retrieving the underlying descriptor from a FILE* stream, which can be useful for system-level operations.Given Data / Assumptions:The code opens a file with fopen and obtains a FILE* named fp.t = fileno(fp); is evaluated.We assume a successful fopen and a standard C library where fileno is available.Concept / Approach:fileno(FILE stream) returns the integer file descriptor associated with the given stream.This descriptor is used by low-level I/O functions like read, write, or by OS-specific APIs.It is not the size of the file and is not an undefined garbage value when fp is valid.Step-by-Step Solution:Call fopen → receive a valid FILE (fp).Call fileno(fp) → get integer descriptor tied to fp.Assign to t → t now holds the OS file handle/file descriptor number.Verification / Alternative check:Printing t typically shows small integers (e.g., 3, 4, 5) corresponding to descriptors opened by the process.Why Other Options Are Wrong:File size: fileno does not compute sizes; use fseek/ftell or stat for that.Garbage value: Only if fp were invalid; with a valid stream, the descriptor is meaningful.Error in fileno(): Not when called correctly with a valid stream.Common Pitfalls:Using fileno portably across platforms requires care; names differ on some systems.Mixing buffered stdio with unbuffered system calls can require explicit fflush/fsync.Final Answer:The handle associated with "DUMMY.C" file

Question 8

What does the FILE* returned by fopen actually point to in C? Consider FILE fp; fp = fopen("trial", "r");

Accepted Answer

Introduction / Context:Many beginners think a FILE points directly to file contents. In reality, FILE is an opaque structure managed by the C runtime that holds buffering state, an internal position indicator, and an association with an underlying file descriptor. Understanding this distinction helps avoid misconceptions about pointer arithmetic on FILE* and clarifies how stdio buffering works.Given Data / Assumptions:We use fopen to obtain a FILE* stream pointer.Standard I/O buffering and FILE abstraction apply.We are not using memory-mapped I/O here.Concept / Approach:FILE* points to a C library structure (opaque to user code).That structure typically contains a buffer, status flags, and bookkeeping including a pointer into the buffer and an underlying file descriptor.It does not point to the first or last character of the actual file on disk.Step-by-Step Explanation:Call fopen("trial","r") → runtime allocates/initializes a FILE object.fp holds the address of that FILE object in memory.The FILE object manages buffered access to file data via getc/putc, fread/fwrite, etc.Verification / Alternative check:Trying to dereference fp as if it were a char* is a type error; only stdio functions should use it.Why Other Options Are Wrong:The first/last character in the file: A FILE* does not point to file contents directly; it is a handle to a stream structure.The name of the file: The stream is not a string; it is a structured object.Common Pitfalls:Assuming fp+1 advances in the file; pointer arithmetic on FILE* is invalid.Forgetting to close the stream with fclose to flush buffers and release resources.Final Answer:A structure which contains a char pointer which points to the first character of a file.

Question 9

Effect of fseek in a read loop: Given the code that copies from source.txt to target.txt but calls fseek(fs, 4L, SEEK_CUR) after each character read, what will be written to 'target.txt' if the source line is "To err is human"?

Accepted Answer

Introduction / Context:This problem tests understanding of file positioning functions in C, specifically how fseek interacts with sequential reading in a loop. By skipping a fixed number of bytes after each successful read, the program samples characters at a specific stride across the source text. Predicting the resulting output requires careful attention to the order of operations and the stride length.Given Data / Assumptions:Source text is exactly: "To err is human" (including spaces, no trailing newline considered).The loop reads one character at a time using getc(fs).After each non-EOF character, the code executes fseek(fs, 4L, SEEK_CUR) and then writes the character to the output with fputc.Files open in text mode; each seek moves the position in bytes across this ASCII text.Concept / Approach:Each iteration reads one byte, then skips forward 4 bytes due to fseek with SEEK_CUR.This creates an effective stride of 5 bytes per iteration (1 read + 4 skipped).The resulting output is every 5th character of the source, starting from index 0.Step-by-Step Solution:Index characters (0-based): 0:T, 1:o, 2: , 3:e, 4:r, 5:r, 6: , 7:i, 8:s, 9: , 10:h, 11:u, 12:m, 13:a, 14:n.Iteration 1: read index 0 → 'T'; seek +4 → next read index 5.Iteration 2: read index 5 → 'r'; seek +4 → next read index 10.Iteration 3: read index 10 → 'h'; seek +4 → next would be index 15 (past end) → EOF, loop ends.Verification / Alternative check:Concatenate captured characters → 'T' + 'r' + 'h' = 'Trh', matching the predicted output.Why Other Options Are Wrong:'r n': Misinterprets spacing and skip pattern; does not align with the 5-byte stride.'err': Would require reading contiguous indices 2–4 or similar, which the code does not do.None of above: Incorrect because 'Trh' is precisely produced by the loop.Common Pitfalls:Forgetting that the seek occurs after the character is read and queued for write.Assuming fseek skips characters without considering the initial position and EOF handling.Final Answer:Trh

Question 10

C file modes: Given FILE *fp; fp = fopen('NOTES.TXT', 'r+'); which operations on the file are permitted by the mode 'r+' (read/update without truncation)?

Accepted Answer

Introduction / Context:In C standard I/O, the two-character (or three-character) mode string passed to fopen controls not only whether a file is opened for reading or writing, but also whether it is treated as text or binary, whether content is preserved or truncated, and whether writes append at end. Understanding the exact meaning of each mode prevents accidental data loss and enables the correct combination of reading and writing behaviors for update-style workflows.Given Data / Assumptions:Code uses: FILE *fp; fp = fopen('NOTES.TXT', 'r+');We assume the file exists and can be opened.Platform is a standard-conforming C environment; text vs. binary is not explicitly specified (no 'b').Concept / Approach:Mode 'r' means open an existing file for reading; the file must already exist.Adding '+' upgrades the stream to update mode: both input and output are permitted on the same stream.Without an 'a' (append) or 'w' (write-truncate) component, the file is neither truncated nor forced to append-only. You may read and write anywhere (subject to fseek/fflush rules between direction changes).Step-by-Step Solution:Interpret 'r+' → existing file, readable and writable, no truncation.Check appending semantics → not implied; writes start at current position (often the beginning) unless moved.Therefore, the permitted operations are both reading and writing (update I/O), not append-only.Verification / Alternative check:Compare with related modes: 'w+' creates/truncates then read/write; 'a+' opens (or creates) and positions at end for each write (append), still allowing reads after seeks.Why Other Options Are Wrong:Reading: Incomplete; 'r+' also allows writing.Writing: Incomplete; 'r+' also allows reading.Appending: That is characteristic of 'a'/'a+' modes, not 'r+'.None of the above: Incorrect because 'Read and Write' precisely describes 'r+'.Common Pitfalls:Forgetting to call fflush or fseek between a read then write (or vice versa) on the same update stream; the C standard requires a positioning or flush operation when switching direction.Assuming 'r+' creates the file if missing; it does not—use 'w+' or 'a+' when creation is needed.Final Answer:Read and Write

Question 11

In C file handling, two streams open the same file in write mode. After writing a character through each stream, what remains in the file?  #include <stdio.h>  int main() {  FILE *fp1, *fp2;  fp1 = fopen("file.c", "w");  fp2 = fopen("file.c", "w"); …

Accepted Answer

Introduction / Context:This question assesses understanding of fopen modes and how multiple write-mode openings affect file contents. Opening in mode "w" truncates the file immediately, and each stream maintains its own file position.Given Data / Assumptions:Both fp1 and fp2 open the same path with mode "w".Each stream begins at file position 0 after its own truncation.Writes occur in the order: 'A' via fp1, then 'B' via fp2.Concept / Approach:The second fopen("w") truncates the file again. Each subsequent fputc writes at that stream's current position (start). Because the final write is 'B' through fp2, the byte at position 0 becomes 'B'. No other bytes are written.Step-by-Step Solution:fp1 opens → file truncated → position 0.fp2 opens → file truncated again → position 0.fputc('A', fp1) writes 'A' at pos 0 in fp1's view.fputc('B', fp2) writes 'B' at pos 0 via fp2, overwriting earlier content.Close both → final file contains exactly 'B'.Verification / Alternative check:Reading the file after the program exits yields a single-byte file with ASCII 'B'.Why Other Options Are Wrong:"A B" suggests two bytes written, but each stream wrote only once at position 0. "B B" implies two bytes; not the case. The filename in the error option is different and there is no error shown.Common Pitfalls:Assuming streams coordinate positions automatically; they do not. Each stream has its own buffer and file position.Final Answer:B

Question 12

In C formatting, what is the exact output produced by adjacent string literal concatenation and a ternary expression?  #include <stdio.h>  int main() {  int k = 1;  printf("%d == 1 is" "%s ", k, k == 1 ? "TRUE" : "FALSE");  return 0; }

Accepted Answer

Introduction / Context:The problem demonstrates two C features: (1) adjacent string literals are concatenated at compile time, and (2) the ternary operator chooses the appropriate string to print. It asks for the exact text produced, including spacing.Given Data / Assumptions:k is 1.The format string is written as two adjacent literals: "%d == 1 is" and "%s".Concatenation creates the single format string "%d == 1 is%s" (note the absence of a space before %s).Concept / Approach:Because k equals 1, the conditional expression selects "TRUE". The printf therefore substitutes k for %d and "TRUE" for %s. There is no extra space inserted between "is" and the %s field—so the output joins them directly.Step-by-Step Solution:Concatenated format → "%d == 1 is%s".Substitute k = 1 and string "TRUE".Printed line → "1 == 1 isTRUE" followed by a newline.Verification / Alternative check:Adding a space inside the first literal (e.g., "is ") would yield "1 == 1 is TRUE"; however, the given code has no space.Why Other Options Are Wrong:Options with a space do not match the exact format. The false option contradicts k == 1. The one using a lowercase k misprints the literal text.Common Pitfalls:Assuming printf inserts a space automatically; it does not. Spacing must be explicit in the format string.Final Answer:1 == 1 isTRUE

Question 13

In C file I/O, what happens when fgetc() is compared to NULL and the character variable is of type char?  #include <stdio.h>  int main() {  FILE *ptr;  char i;  ptr = fopen("myfile.c", "r");  while ((i = fgetc(ptr)) != NULL)  printf("%c", i);  retur…

Accepted Answer

Introduction / Context:This question evaluates understanding of correct end-of-file handling in C. The function fgetc returns an int so it can signal EOF as a negative value (typically -1). Comparing its result to NULL (0) and storing it in a char leads to a logic error.Given Data / Assumptions:i is of type char.Loop condition compares result to NULL (0) rather than EOF (-1).At EOF, fgetc returns EOF each time it is called.Concept / Approach:Assigning fgetc's int result to a char truncates it. If char is unsigned on the implementation, EOF becomes 255 (not equal to 0) and the condition != NULL remains true forever, repeatedly reading EOF and printing undefined characters. Even with signed char, the condition used is still wrong; the correct test is to use an int and compare to EOF.Step-by-Step Solution:Use an int: int c;Read: while ((c = fgetc(ptr)) != EOF) putchar(c);Given code instead uses char i and compares to 0 → EOF never terminates the loop.Verification / Alternative check:Test with a small file; observe the program does not terminate and keeps calling fgetc returning EOF.Why Other Options Are Wrong:It will not stop at a NULL byte because text files rarely contain one, and the comparison is not checking for EOF correctly. The code compiles, so “Error in program” (compile-time) is misleading.Common Pitfalls:Using char for fgetc, and comparing against 0 or '\0' rather than EOF.Final Answer:Infinite loop

Question 14

In C printf formatting, what is the rounded output for a floating value with one digit after the decimal point?  #include <stdio.h>  int main() {  float a = 3.15529f;  printf("%2.1f ", a);  return 0; }

Accepted Answer

Introduction / Context:This question checks knowledge of printf's floating-point formatting and rounding behavior. The format %2.1f requests exactly one digit after the decimal point, with a minimum field width of 2.Given Data / Assumptions:a = 3.15529.Format string is "%2.1f".Default rounding of printf for .1 precision is to the nearest representable, commonly half-up behavior for ties once converted to decimal.Concept / Approach:Rounding 3.15529 to one decimal place yields 3.2. The width specifier 2 simply sets a minimum field width; it does not truncate digits beyond the requested precision nor suppress the decimal point.Step-by-Step Solution:Desired precision = 1 decimal → round 3.15529 to 3.2.Output printed as a fixed-point number with one digit after the decimal → "3.2".Verification / Alternative check:Printing with higher precision first (e.g., %.3f) shows 3.155, confirming the next digit is 2, so rounding to one decimal produces 3.2.Why Other Options Are Wrong:3.15 has two decimals; 3.00 is over-rounded down; 3 is an integer-like rendering and does not match %.1f formatting.Common Pitfalls:Confusing field width with precision, and expecting integer output for %f.Final Answer:3.2

Question 15

In C printf, assume the intent is to print a decimal integer with a minimal field width of 1. What does this program output (ignoring a stray non-printing control glyph in the source)?  #include <stdio.h>  int main() {  int a = 250;  printf("%1d", a…

Accepted Answer

Introduction / Context:The original snippet shows "%1d" followed by an unusual control character. Applying the Recovery-First Policy, we interpret the intent as printing the integer with the standard format "%1d". Field width 1 is the minimum width, so any multi-digit number prints fully.Given Data / Assumptions:a = 250.Format is effectively "%1d" (minimum width 1).No additional flags or precision are set.Concept / Approach:In printf, the field width is a minimum. If the value needs more columns, it expands to fit. Therefore, a three-digit number like 250 prints as "250" without truncation.Step-by-Step Solution:Compute textual representation of 250 → "250".Compare with field width 1 → width is satisfied; no padding necessary.Printed result is exactly "250".Verification / Alternative check:Testing with widths smaller or larger (e.g., %5d) changes only padding, not the digits themselves.Why Other Options Are Wrong:"2" or "50" would imply truncation, which printf does not do for integers. "1250" would require a different argument, not present here.Common Pitfalls:Misunderstanding field width as a directive to clip digits rather than a minimum width for padding.Final Answer:250

Question 16

In C file positioning, given a file containing "This is Nagpur", what substring is printed after seeking forward and reading with fgets?  #include <stdio.h>  int main() {  FILE fp;  char ch, str[7];  fp = fopen("try.c", "r"); / file 'try.c' contains…

Accepted Answer

Introduction / Context:This problem checks understanding of byte-wise seeking and bounded line input. fseek moves the file position indicator, and fgets reads a limited number of bytes into a buffer, appending a null terminator.Given Data / Assumptions:File text: "This is Nagpur" (indices: T0 h1 i2 s3 4 i5 s6 7 N8 a9 g10 p11 u12 r13).fseek(fp, 9L, SEEK_CUR) from the start puts the position at index 9 (character 'a').fgets(str, 5, fp) reads at most 4 characters plus a terminator into str.Concept / Approach:Starting at index 9 ('a'), reading 4 characters yields 'a', 'g', 'p', 'u'. fgets writes those and appends '\0', so the buffer contains "agpu".Step-by-Step Solution:Seek to index 9 → current char = 'a'.Read 4 chars with fgets → 'a', 'g', 'p', 'u'.Buffer becomes "agpu" → puts prints "agpu" plus a newline.Verification / Alternative check:Changing the second argument of fgets to 6 would read 5 characters → "agpur".Why Other Options Are Wrong:"Nagp" would require starting at 'N' (index 8). "gpur" starts at index 10, not 9. "agpur" reads 5 letters, exceeding the given size.Common Pitfalls:Forgetting that fgets counts the terminator in its size and stops after size-1 characters.Final Answer:agpu

Question 17

In C, what does scanf return when it successfully reads one decimal integer? Consider the following minimal program and assume the user enters 25.  #include <stdio.h>  int main() {  int i;  printf("%d ", scanf("%d", &i));  return 0; }

Accepted Answer

Introduction / Context:This question is about scanf's return value. scanf returns the number of input items successfully matched and assigned, not the values read, and not the number of characters consumed.Given Data / Assumptions:Format string is "%d".The input provided is 25.i is a valid pointer target of type int.Concept / Approach:When scanf matches one %d and stores it into i, it returns 1 to indicate one item successfully assigned. If input is malformed or EOF occurs before assignment, it would return 0 or EOF respectively.Step-by-Step Solution:scanf tries to match a single integer token."25" matches → conversion succeeds → i receives 25.Return value becomes 1; printf prints 1.Verification / Alternative check:Entering non-numeric text such as "hi" would cause scanf to return 0. Piping EOF immediately typically yields EOF (often -1) depending on library.Why Other Options Are Wrong:"25" is the value assigned, not the return count. "2" and "5" are unrelated to scanf's return semantics here.Common Pitfalls:Assuming scanf returns the parsed value rather than the count of successful conversions.Final Answer:1

Question 18

In C file I/O, what does this program print from a file until EOF, and what happens in the final printf call? #include #include int main() { FILE fp; unsigned char ch; / file 'abc.c' contains: "This is CuriousTab " / fp = …

Accepted Answer

Introduction / Context:This question focuses on correct EOF-controlled reading and format-string behavior in printf. The loop prints each character from the file until EOF; the final printf prints a newline regardless of the unused extra argument.Given Data / Assumptions:File text is "This is CuriousTab ".getc returns the next byte as an int and EOF when the end is reached.Variable ch is unsigned char but the comparison using getc's return value is still valid because the assignment happens before the comparison.Concept / Approach:In while ((ch = getc(fp)) != EOF), getc returns an int. The assignment to ch then converts the lower 8 bits, but the comparison uses the promoted int from the assignment expression, which holds the original getc result. As long as the character read is not EOF, the body prints it. After the loop, fclose closes the stream. The final printf("", ch) ignores the superfluous argument and prints only a newline.Step-by-Step Solution:Read and echo characters → outputs "This is CuriousTab " including the trailing space.Close file → emit a newline.Net visible line → "This is CuriousTab" (trailing space not visible at the end in the option wording).Verification / Alternative check:Replace getc with fgetc and store into an int to avoid any subtlety with unsigned char; output is the same.Why Other Options Are Wrong:It is not an infinite loop and there is no error. Truncating at "This is" would require an early stop condition that does not exist here.Common Pitfalls:Misusing printf format strings (unused arguments are ignored) and misunderstanding the role of EOF and int return types for character input.Final Answer:This is CuriousTab

Question 19

In C programming, evaluate the character printed by this expression that mixes arithmetic and bitwise operators. What will be the output?  #include<stdio.h>  int main() { printf("%c ", ~('C' * -1)); return 0; }

Accepted Answer

Introduction / Context:This program tests how C promotes character constants to int, how unary negation works on integers, and how the bitwise NOT operator interacts with two’s-complement arithmetic. Understanding usual arithmetic conversions and identities like ~x = -x - 1 is key to predicting the exact character printed.Given Data / Assumptions:The character constant 'C' has ASCII code 67.In expressions, character constants are promoted to type int.Two’s-complement arithmetic is assumed (the de facto representation on modern systems).The operator precedence is: multiplication before unary ~, and unary - binds tightly to the literal -1.Concept / Approach:The expression is ~('C' * -1). First compute the product as an int, then apply the bitwise NOT. For two’s complement integers, there is a helpful identity: ~x = -x - 1. We will use this on x = -67 to avoid writing long bit patterns.Step-by-Step Solution:Interpret 'C' → 67.Compute product: 67 * -1 = -67.Apply identity: ~(-67) = -(-67) - 1 = 67 - 1 = 66.Convert 66 to a character for %c → ASCII 66 is 'B'.printf prints B followed by a newline.Verification / Alternative check:If you explicitly write out two’s-complement bits, -67 has all ones except the magnitude pattern; inverting flips all bits, which numerically equals 66. Printing as %d would show 66; as %c it shows 'B'.Why Other Options Are Wrong:'A' and 'D' are off by more than one step and ignore the exact arithmetic. 'C' would imply no change after the operations. The “implementation-defined” choice does not apply here because the arithmetic result is well defined under two’s complement, which is overwhelmingly standard.Common Pitfalls:Confusing bitwise NOT with arithmetic negation, or assuming 'C' remains a char without integer promotion. Also, forgetting that %c prints the character for the computed code.Final Answer:B

Question 20

In C, pointer arithmetic on a format string: what does this print?  #include<stdio.h>  int main() { char *p; p = "%d "; p++; p++; printf(p - 2, 23); return 0; }

Accepted Answer

Introduction / Context:This question checks your understanding of pointer arithmetic with string literals and how printf uses a format-string pointer. Although the code moves the pointer forward and then back, it ultimately passes a valid format string to printf.Given Data / Assumptions:p points to the literal "%d". In memory this is the byte sequence '%', 'd', '', '\0'.p++ twice advances p to point at ''.printf expects a format string as its first argument.Concept / Approach:Pointer arithmetic is reversible. After two increments, p points at the newline byte. Subtracting 2 returns to the original base address where the '%' character resides. Passing p - 2 to printf therefore provides a valid "%d" format string, and 23 is the integer argument to format and print.Step-by-Step Solution:Initial: p → '%' of "%d".After p++ twice: p → ''.Compute p - 2: pointer again points to '%'.printf(p - 2, 23) is equivalent to printf("%d", 23).Therefore the program prints 23 followed by a newline.Verification / Alternative check:Replace printf(p - 2, 23) with printf("%d", 23) to confirm identical behavior. Running the original code prints 23 because the pointer arithmetic returns to the correct start of the format.Why Other Options Are Wrong:21 assumes arithmetic on the number, not on the pointer. “Error” or “No output” would occur only if an invalid pointer were passed, which does not happen here. It is not undefined behavior because the resulting pointer still points within the same array object (the literal), which is permitted.Common Pitfalls:Assuming that advanced pointer gymnastics are inherently invalid; forgetting that format strings are just char arrays and pointer math can legally traverse them.Final Answer:23

Input / Output Questions

Questions

Practice smarter