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 (
). 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 
 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 ) is also copied verbatim. After copying, fgets appends a null terminator \0. Step-by-Step Solution: Input stream bytes → 'I am a boy
'.fgets copies bytes until and including 
, so both  and 
 end up in the buffer.fgets appends \0, yielding 'I am a boy
\0' in memory. Verification / Alternative check: Printing with debugging or inspecting byte values shows 0x0D (), 0x0A (
), followed by 0x00. Why Other Options Are Wrong: "I am a boy\0": Would imply fgets stops at , which it does not; it stops after copying 
. "I am a boy
\0": Ignores the presence of  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 . For cross-platform trimming, explicitly remove trailing  and 
 as needed. Final Answer: "I am a boy
\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

What will be the content of 'file.c' after executing the following program? #include<stdio.h>  int main() {     FILE *fp1, *fp2;     fp1=fopen("file.c", "w");     fp2=fopen("file.c", "w");     fputc('A', fp1);     fputc('B', fp2);     fclose(fp1);  …

Accepted Answer

Here fputc('A', fp1); stores 'A' in the file1.c then fputc('B', fp2); overwrites the contents of the file1.c with value 'B'. Because the fp1 and fp2 opens the file1.c in write mode. Hence the file1.c contents is 'B'.

Question 12

What will be the output of the program? #include<stdio.h>  int main() {     int k=1;     printf("%d == 1 is" "%s ", k, k==1?"TRUE":"FALSE");     return 0; }

Accepted Answer

Step 1: int k=1; The variable k is declared as an integer type and initialized to '1'. Step 2: printf("%d == 1 is" "%s
", k, k==1?"TRUE":"FALSE"); becomes => k==1?"TRUE":"FALSE" => 1==1?"TRUE":"FALSE" => "TRUE" Therefore the output of the program is 1 == 1 is TRUE

Question 13

What will be the output of the program? #include<stdio.h>  int main() {     FILE *ptr;     char i;     ptr = fopen("myfile.c", "r");     while((i=fgetc(ptr))!=NULL)         printf("%c", i);     return 0; }

Accepted Answer

The program will generate infinite loop. When an EOF is encountered fgetc() returns EOF. Instead of checking the condition for EOF we have checked it for NULL. so the program will generate infinite loop.

Question 14

What will be the output of the program? #include<stdio.h>  int main() {     float a=3.15529;     printf("%2.1f ", a);     return 0; }

Accepted Answer

float a=3.15529; The variable a is declared as an float data type and initialized to value 3.15529; printf("%2.1f
", a); The precision specifier tells .1f tells the printf function to place only one number after the .(dot). Hence the output is 3.2

Question 15

What will be the output of the program? #include<stdio.h>  int main() {     int a=250;     printf("%1d ", a);     return 0; }

Accepted Answer

int a=250; The variable a is declared as an integer type and initialized to value 250. printf("%1d
", a); It prints the value of variable a. Hence the output of the program is 250.

Question 16

What will be the output of the program? #include<stdio.h>  int main() {     FILE *fp;     char ch, str[7];     fp=fopen("try.c", "r"); /* file 'try.c' contains "This is Nagpur" */     fseek(fp, 9L, SEEK_CUR);     fgets(str, 5, fp);     puts(str);   …

Accepted Answer

agpu

Question 17

What will be the output of the program if value 25 given to scanf()? #include<stdio.h>  int main() {     int i;     printf("%d ", scanf("%d", &i));     return 0; }

Accepted Answer

The scanf function returns the number of input is given. printf("%d
", scanf("%d", &i)); The scanf function returns the value 1(one). Therefore, the output of the program is '1'.

Question 18

What will be the output of the program? #include<stdio.h>  int main() {     FILE *fp;     unsigned char ch;      /* file 'abc.c' contains "This is CuriousTab " */     fp=fopen("abc.c", "r");     if(fp == NULL)     {         printf("Unable …

Accepted Answer

The macro EOF means -1. while((ch=getc(fp)) != EOF) Here getc function read the character and convert it to an integer value and store it in the variable ch, but it is declared as an unsigned char. So the while loop runs infinitely.

Question 19

What will be the output of the program? #include<stdio.h>  int main() {     printf("%c ", ~('C'*-1));     return 0; }

Accepted Answer

B

Question 20

What will be the output of the program? #include<stdio.h>  int main() {     char *p;     p="%d ";     p++;     p++;     printf(p-2, 23);     return 0; }

Accepted Answer

23

Input / Output Questions