Point Out Errors

Correct Answer: C. No error ✅

Consider the following C program:

#include<stdio.h>
#include<stdlib.h>

int main()
{
    unsigned char;
    FILE *fp;

    fp = fopen("trial", "r");

    if(!fp)
    {
        printf("Unable to open file");
        exit(1);
    }

    fclose(fp);

    return 0;
}

The statement:

unsigned char;

looks unusual, but it is not a compilation error. According to the C grammar, a declaration may consist solely of declaration specifiers without declaring any variable. Such a declaration has no effect and is typically reported only as a warning (for example, "useless type name in empty declaration") by many compilers.

The rest of the program is also correct:

• FILE *fp; is a valid file pointer declaration.
• fopen() opens the file for reading.
• The NULL check is correct.
• fclose(fp); correctly closes the file.

• A. Error: in unsigned char statement ❌
  Incorrect. Although the declaration is useless, it is valid C and does not produce a compilation error.
• B. Error: unknown file pointer ❌
  Incorrect. FILE *fp; is a valid declaration.
• C. No error ✅
  Correct. The program is syntactically valid. At most, the compiler may issue a warning about the empty declaration.
• D. None of above ❌
  Incorrect. Option C is correct.

Exam Fact:
An empty declaration such as unsigned char; is valid in C but has no effect. Many compilers generate a warning like useless type name in empty declaration, but it is not a compilation error.

Correct Answer: B. Error: we may not get input for second scanf() statement ✅

Consider the following C program:

#include<stdio.h>

int main()
{
    char ch;
    int i;

    scanf("%c", &i);
    scanf("%d", &ch);

    printf("%c %d", ch, i);

    return 0;
}

Note: Strictly speaking, both scanf() statements use incorrect format specifiers:

• %c expects a char *, but &i is an int *.
• %d expects an int *, but &ch is a char *.

However, this question is a well-known competitive exam question whose official expected answer is Option B. The intended concept is that after a scanf("%c", ...), input handling may affect the next scanf() because of leftover characters (such as a newline) in the input buffer.

• A. Error: suspicious char to int conversion in scanf() ❌
  Although modern compilers generate warnings due to mismatched argument types, this is not the officially expected answer for this competitive exam question.
• B. Error: we may not get input for second scanf() statement ✅
  Correct as per the official answer key. The question intends to test the common issue of consecutive scanf() calls and input buffering.
• C. No error ❌
  Incorrect. The program contains issues.
• D. None of above ❌
  Incorrect. The official answer is Option B.

Exam Fact:
The official answer is B. In real C programming, the more fundamental issue is that the format specifiers do not match the argument types, which results in undefined behavior. This is one of those older competitive-programming questions where the expected answer differs from what modern compilers and the C standard emphasize.

Correct Answer: B. Error: fseek() long offset value ✅

Consider the following C program:

#include<stdio.h>

int main()
{
    FILE *fp;

    fp = fopen("trial", "r");

    fseek(fp, "20", SEEK_SET);

    fclose(fp);

    return 0;
}

The prototype of fseek() is:

int fseek(FILE *stream, long int offset, int origin);

The second argument (offset) must be of type long int. However, the program passes:

"20"

The expression "20" is a string literal, whose type is a character array (used as a pointer to its first element). It is not a numeric long value.

The correct call should be:

fseek(fp, 20L, SEEK_SET);

or

fseek(fp, 20, SEEK_SET);

• A. Error: unrecognised Keyword SEEK_SET ❌
  Incorrect. SEEK_SET is a valid macro defined in <stdio.h>.
• B. Error: fseek() long offset value ✅
  Correct. The second argument should be a numeric long offset, not the string literal "20".
• C. No error ❌
  Incorrect. The call to fseek() uses an invalid type for the offset argument.
• D. None of above ❌
  Incorrect. Option B correctly identifies the error.

Exam Fact:
The syntax of fseek() is fseek(FILE *stream, long offset, int origin). The offset must be an integer value (typically written as 20L for a long). String literals such as "20" cannot be used as the offset.

Correct Answer: C. Output: Unable to open file. ✅

Consider the following C program:

#include<stdio.h>

/* Assume there is a file called 'file.c' in c:\tc directory. */

int main()
{
    FILE *fp;

    fp = fopen("c:\tc\file.c", "r");

    if(!fp)
        printf("Unable to open file.");

    fclose(fp);

    return 0;
}

The problem lies in the file path:

"c:\tc\file.c"

In C, the backslash (\) is used to begin an escape sequence. Therefore:

• \t is interpreted as a tab character.
• \f is interpreted as a form feed character.

So the string:

"c:\tc\file.c"

is actually interpreted as something similar to:

c:    cile.c

which is not the intended file path. As a result, fopen() fails and returns NULL. Therefore, the condition:

if(!fp)
    printf("Unable to open file.");

is executed, producing the output:

Unable to open file.

The correct way to specify the path is:

fp = fopen("c:\\tc\\file.c", "r");

or

fp = fopen("c:/tc/file.c", "r");

• A. No error, No output. ❌
  Incorrect. The path is interpreted incorrectly because of escape sequences.
• B. Program crashes at run time. ❌
  Incorrect. Although fclose(fp) with a NULL pointer results in undefined behavior, the intended exam answer focuses on the failed fopen() call and its output.
• C. Output: Unable to open file. ✅
  Correct. The incorrect path causes fopen() to fail, so the message is printed.
• D. None of above ❌
  Incorrect. Option C is the expected answer.

Exam Fact:
In C string literals, the backslash (\) introduces escape sequences such as \n, \t, and \f. Windows file paths should be written as "C:\\folder\\file.txt" or by using forward slashes ("C:/folder/file.txt").

Correct Answer: A. Error: in unsigned char declaration ✅

Consider the following C program:

#include<stdio.h>

int main()
{
    unsigned char ch;
    FILE *fp;

    fp = fopen("trial", "r");

    while((ch = getc(fp)) != EOF)
        printf("%c", ch);

    fclose(fp);

    return 0;
}

The variable ch is declared as:

unsigned char ch;

The function getc() returns an int, not a char. It returns either:

• A character value (converted to int), or
• EOF (typically -1) when the end of the file is reached.

Since ch is an unsigned char, it cannot correctly represent the value EOF. Therefore, using an unsigned char to store the return value of getc() is incorrect. The correct declaration is:

int ch;

• A. Error: in unsigned char declaration ✅
  Correct as per the official answer. The return value of getc() should be stored in an int, not an unsigned char.
• B. Error: while statement ❌
  Although the while condition fails because EOF cannot be detected correctly, the official answer attributes the problem to the declaration of ch.
• C. No error ❌
  Incorrect. The program does not correctly handle EOF.
• D. It prints all characters in file "trial" ❌
  Incorrect. The loop does not terminate properly when the end of the file is reached.

Exam Fact:
The return value of getc() (and fgetc()) should always be stored in an int, because it must be able to represent every valid character value as well as the special value EOF. Although the loop is where the failure appears, the root cause is the declaration of ch as unsigned char, which is why the official answer is Option A.