Command Line Arguments Questions and Answers

Q: A program that has no command line arguments will have argc _________

Correct answer: OneThe program name occupies argv[0] and is counted, so argc is 1 when nothing else is supplied.That is why a program testing for arguments writes if (argc > 1) rather than if (argc). The standard permits argc to be 0, in which case argv[0] is a null pointer, but this happens only where a program is started by an exec call that supplies no name at all - never from an ordinary shell.

Q: What is the index of the last argument in command line arguments?

Correct answer: argc - 1The vector is indexed from 0 and holds argc strings, so the valid indices run 0 to argc-1 and the last argument is at argc-1.argv[argc] exists but is the guaranteed null pointer terminating the array, not an argument. Reading it as a string is the mistake the companion questions turn on, and beyond it - argv[argc+1] - nothing is defined at all.

Q: What will be the output of the following C code (if run with no options or arguments)? #include <stdio.h> int main(int argc, char *argv[]) { printf("%d\n", argc); return 0; }

Correct answer: 1Run with no options or arguments, argc is 1: the program name in argv[0] is itself counted.The value is not platform-dependent in any practical sense - the standard requires the program name to be represented and counted when it is available - so the second and third options fail. The single theoretical exception is a program started by an exec call passing no name at all, which gives argc of 0, and no shell does that.

Q: What will be the output of the following C code (run without any command line arguments)? #include <stdio.h> int main(int argc, char *argv[]) { while (argc--) printf("%s\n", argv[argc]); return 0; }

Correct answer: ExecutablefilenameWith no arguments argc is 1. The condition while (argc--) tests the current value and then decrements, so the first test sees 1, which is true, and the body runs with argc now 0.The call is therefore printf("%s\n", argv[0]), printing the program name. The next test sees 0, which is false, and the loop ends. The post-decrement is what makes the indexing come out right: the value tested and the index used differ by one.

Q: What will be the output of the following C code (run without any command line arguments)? #include <stdio.h> int main(int argc, char *argv[]) { printf("%s\n", argv[argc]); return 0; }

Correct answer: Segmentation fault/code crashWith no arguments argc is 1, so argv[argc] is argv[1] - the guaranteed null pointer at the end of the vector.Passing a null pointer to %s is undefined behaviour, and the crash the key reports is what an implementation that simply dereferences it produces. The GNU C library instead detects the case and prints (null), which is why the same construct appears elsewhere with that answer - the code is unsafe either way and its result cannot be relied on.

Q: What will be the output of the following C code (run without any command line arguments)? #include <stdio.h> int main(int argc, char *argv[]) { while (*argv++ != NULL) printf("%s\n", *argv); return 0; }

Correct answer: Segmentation fault/code crashThe post-increment is the trap. The condition tests *argv, which is argv[0] and non-null, and then advances the pointer - so by the time the body runs, *argv is argv[1].With no arguments argv[1] is the terminating null pointer, so the very first printf is handed NULL for %s. The loop tests one element and prints the next, which is exactly one element out of step; moving the increment into the printf instead, as the companion question does, corrects it.

Q: What will be the output of the following C code (run without any command line arguments)? #include <stdio.h> int main(int argc, char *argv[]) { while (*argv != NULL) printf("%s\n", *(argv++)); return 0; }

Correct answer: Executable file nameHere the increment is in the body rather than the condition, and that makes the difference. The test examines *argv - argv[0], non-null - and the printf then prints that same element before advancing the pointer.So the program name is printed. The next test finds argv[1], which with no arguments is the terminating null pointer, and the loop ends cleanly. Testing and printing the same element is what keeps this version correct where the companion is one out of step.

Q: What will be the output of the following C code (run without any command line arguments)? #include <stdio.h> int main(int argc, char *argv[]) { while (argv != NULL) printf("%s\n", *(argv++)); return 0; }

Correct answer: Segmentation fault/code crashThe condition tests argv rather than *argv, and argv is a pointer into the array - it is never itself null however far it is advanced.The loop therefore never terminates. It prints argv[0], then the terminating null pointer, then whatever lies beyond the array, walking off the end of the block until it reaches unmapped memory and the program is killed. One * separates this from the working version: the null to test for is the one stored in the array.

Q: What is the output of this C code? #include <stdio.h> int main() { char *p = NULL; char *q = 0; if (p) printf(" p "); else printf("nullp"); if (q) printf("q\n"); else printf(" nullq\n"); }

Correct answer: nullp nullqBoth pointers are null. NULL is a null pointer constant, and so is a literal 0 in a pointer context - the compiler converts it, which is why char *q = 0; is legal and gives the same value as = NULL.A null pointer tests false in a condition, so both if statements take their else branch. Note that the internal representation is not required to be all-zero bits; what the standard guarantees is the conversion from the constant 0 and the comparison, which is all the program relies on.

Q: What is the output of this C code? #include <stdio.h> int main() { int i = 10; void *p = &i; printf("%d\n", (int)*p); return 0; }

Correct answer: Compile time errorvoid is an incomplete type, so *p on a void * has no type and no size and the compiler rejects it. The cast in (int)*p comes too late: the dereference must be resolved before anything can be cast.The correct form casts the pointer first, as *(int *)p, telling the compiler how to read the memory before reading it. That is exactly what the companion question does with a float *, and it is why void * can carry any object pointer but can be dereferenced through none.

31.

A program that has no command line arguments will have argc _________

A.Zero
B.Negative
C.One
D.Two

Answer: C

Correct answer: One

The program name occupies argv[0] and is counted, so argc is 1 when nothing else is supplied.

That is why a program testing for arguments writes if (argc > 1) rather than if (argc). The standard permits argc to be 0, in which case argv[0] is a null pointer, but this happens only where a program is started by an exec call that supplies no name at all - never from an ordinary shell.

Discuss in Forum

32.

What is the index of the last argument in command line arguments?

A.argc - 2
B.argc + 1
C.argc
D.argc - 1

Answer: D

Correct answer: argc - 1

The vector is indexed from 0 and holds argc strings, so the valid indices run 0 to argc-1 and the last argument is at argc-1.

argv[argc] exists but is the guaranteed null pointer terminating the array, not an argument. Reading it as a string is the mistake the companion questions turn on, and beyond it - argv[argc+1] - nothing is defined at all.

Discuss in Forum

33.

What will be the output of the following C code (if run with no options or arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        printf("%d\n", argc);
        return 0;
    }

A.1
B.Depends on the platform
C.Depends on the compiler

Answer: A

Correct answer: 1

Run with no options or arguments, argc is 1: the program name in argv[0] is itself counted.

The value is not platform-dependent in any practical sense - the standard requires the program name to be represented and counted when it is available - so the second and third options fail. The single theoretical exception is a program started by an exec call passing no name at all, which gives argc of 0, and no shell does that.

Discuss in Forum

34.

What will be the output of the following C code (run without any command line arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        while (argc--)
        printf("%s\n", argv[argc]);
        return 0;
    }

A.Compile time error
B.Executablefilename
C.Segmentation fault
D.Undefined

Answer: B

Correct answer: Executablefilename

With no arguments argc is 1. The condition while (argc--) tests the current value and then decrements, so the first test sees 1, which is true, and the body runs with argc now 0.

The call is therefore printf("%s\n", argv[0]), printing the program name. The next test sees 0, which is false, and the loop ends. The post-decrement is what makes the indexing come out right: the value tested and the index used differ by one.

Discuss in Forum

35.

What will be the output of the following C code (run without any command line arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        printf("%s\n", argv[argc]);
        return 0;
    }

A.Segmentation fault/code crash
B.Executable file name
C.Depends on the platform
D.Depends on the compiler

Answer: A

Correct answer: Segmentation fault/code crash

With no arguments argc is 1, so argv[argc] is argv[1] - the guaranteed null pointer at the end of the vector.

Passing a null pointer to %s is undefined behaviour, and the crash the key reports is what an implementation that simply dereferences it produces. The GNU C library instead detects the case and prints (null), which is why the same construct appears elsewhere with that answer - the code is unsafe either way and its result cannot be relied on.

Discuss in Forum

36.

What will be the output of the following C code (run without any command line arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        while (*argv++ != NULL)
        printf("%s\n", *argv);
        return 0;
    }

A.Segmentation fault/code crash
B.Executable file name
C.Depends on the platform
D.Depends on the compiler

Answer: A

Correct answer: Segmentation fault/code crash

The post-increment is the trap. The condition tests *argv, which is argv[0] and non-null, and then advances the pointer - so by the time the body runs, *argv is argv[1].

With no arguments argv[1] is the terminating null pointer, so the very first printf is handed NULL for %s. The loop tests one element and prints the next, which is exactly one element out of step; moving the increment into the printf instead, as the companion question does, corrects it.

Discuss in Forum

37.

What will be the output of the following C code (run without any command line arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        while (*argv  !=  NULL)
        printf("%s\n", *(argv++));
        return 0;
    }

A.Segmentation fault/code crash
B.Executable file name
C.Depends on the platform
D.Depends on the compiler

Answer: B

Correct answer: Executable file name

Here the increment is in the body rather than the condition, and that makes the difference. The test examines *argv - argv[0], non-null - and the printf then prints that same element before advancing the pointer.

So the program name is printed. The next test finds argv[1], which with no arguments is the terminating null pointer, and the loop ends cleanly. Testing and printing the same element is what keeps this version correct where the companion is one out of step.

Discuss in Forum

38.

What will be the output of the following C code (run without any command line arguments)?

#include <stdio.h>
    int main(int argc, char *argv[])
    {
        while (argv != NULL)
        printf("%s\n",  *(argv++));
        return 0;
    }

A.Segmentation fault/code crash
B.Executable file name
C.Depends on the platform
D.Depends on the compiler

Answer: A

Correct answer: Segmentation fault/code crash

The condition tests argv rather than *argv, and argv is a pointer into the array - it is never itself null however far it is advanced.

The loop therefore never terminates. It prints argv[0], then the terminating null pointer, then whatever lies beyond the array, walking off the end of the block until it reaches unmapped memory and the program is killed. One * separates this from the working version: the null to test for is the one stored in the array.

Discuss in Forum

39.

What is the output of this C code?

#include <stdio.h>
    int main()
    {
        char *p = NULL;
        char *q = 0;
        if (p)
            printf(" p ");
        else
            printf("nullp");
        if (q)
            printf("q\n");
        else
            printf(" nullq\n");
    }

A.nullp nullq
B.Depends on the compiler
C.x nullq where x can be p or nullp depending on the value of NULL
D.p q

Answer: A

Correct answer: nullp nullq

Both pointers are null. NULL is a null pointer constant, and so is a literal 0 in a pointer context - the compiler converts it, which is why char *q = 0; is legal and gives the same value as = NULL.

A null pointer tests false in a condition, so both if statements take their else branch. Note that the internal representation is not required to be all-zero bits; what the standard guarantees is the conversion from the constant 0 and the comparison, which is all the program relies on.

Discuss in Forum

40.

What is the output of this C code?

#include <stdio.h>
    int main()
    {
        int i = 10;
        void *p = &i;
        printf("%d\n", (int)*p);
        return 0;
    }

A.Compile time error
B.Segmentation fault/runtime crash
C.10
D.Undefined behaviour

Answer: A

Correct answer: Compile time error

void is an incomplete type, so *p on a void * has no type and no size and the compiler rejects it. The cast in (int)*p comes too late: the dereference must be resolved before anything can be cast.

The correct form casts the pointer first, as *(int *)p, telling the compiler how to read the memory before reading it. That is exactly what the companion question does with a float *, and it is why void * can carry any object pointer but can be dereferenced through none.

Discuss in Forum

Loading…

Topics

Other Subjects

Tags: Command Line Arguments Questions and Answers || Command Line Arguments MCQ Questions and Answers || Command Line Arguments GK Questions and Answers || Command Line Arguments GK MCQ Questions || Command Line Arguments Multiple Choice Questions and Answers || Command Line Arguments GK || GK on Command Line Arguments || C Programming Questions and Answers || C Programming MCQ Questions and Answers || C Programming GK Questions and Answers || GK on C Programming

Command Line Arguments Questions and Answers

Topics

Other Subjects

About Us

Stay informed about all important Dates & Notifications