www.interviewhelper.org is a hope for all the Job seekers. Users can find unlimited here. These range from technical to HR, from functional to behavioral. www.interviewhelper.org contains in the fields like Ajax,VB,Networking,Sharepoint,JEE,Perl,Javascript,Bioinformatics,Classic ASP,Unix,Linux,Accounting,Oracle DBA,Microprocessor,Bluetooth,jms,jme,.net framework,ABAP,ASP,ASP.net,Basic .net Framework,Interview Questions,C language,C++,database,Oracle,Java,PHP,LAMP,SAP etc.
Tuesday, December 18, 2007
C Interview Questions Part - 5
1.1: How do you decide which integer type to use?
---
1.1: How should I decide which integer type to use?
==========
float and double. None of the above rules apply if the address
of a variable is taken and must have a particular type.
---
float and double. None of the above rules apply if pointers to
the variable must have a particular type.
==========
1.4: What should the 64-bit type on a machine that can support it?
---
1.4: What should the 64-bit type be on a machine that can support it?
==========
The .c file containing the definition should also #include the
same header file, so that the compiler can check that the definition
---
same header file, so the compiler can check that the definition
matches the declarations.
==========
clear. The problem with the NODEPTR example is that the typedef
has not been defined at the point where the "next" field is
---
has not yet been defined at the point where the "next" field is
declared.
==========
1.21: How do I declare an array of N pointers to functions returning
pointers to functions returning pointers to characters?
---
1.21: How do I construct and understand declarations of complicated
types such as "array of N pointers to functions returning
pointers to functions returning pointers to char"?
==========
A: The first part of this question can be answered in at least
three ways:
---
A: There are at least three ways of answering this question:
==========
cdecl can also explain complicated declarations, help with
casts, and indicate which set of parentheses the arguments
---
casts, and indicate which set of parentheses the parameters
go in
==========
Any good book on C should explain how to read these complicated C
---
A good book on C should explain how to read these complicated
declarations "inside out" to understand them ("declaration
mimics use").
==========
1.30: What am I allowed to assume about the initial values
of variables which are not explicitly initialized?
---
of variables and arrays which are not explicitly initialized?
==========
A: Uninitialized variables with "static" duration (that is, those
declared outside of functions, and those declared with the
storage class static), are guaranteed to start out as zero,
---
storage class static), are guaranteed to start out as zero, just
as if the programmer had typed "= 0".
==========
A: Is the declaration of a static or non-local variable? Function
calls are allowed only in initializers for automatic variables
---
calls are allowed in initializers only for automatic variables
==========
A: A string literal can be used in two slightly different ways. As
an array initializer (as in the declaration of char a[]), it
---
an array initializer (as in the declaration of char a[] in the
question), it specifies the initial values of the characters in
that array.
==========
Anywhere else, it turns into an unnamed, static array of
characters, which may be stored in read-only memory,
which is why you can't safely modify it.
---
and which therefore cannot necessarily be modified.
==========
(For compiling old code, some compilers have a switch
controlling whether strings are writable or not.)
---
controlling whether string literals are writable or not.)
==========
When the name of a function appears in an expression like this,
---
When the name of a function appears in an expression,
it "decays" into a pointer (that is, it has its address
implicitly taken), much as an array name does.
==========
2.4: What's the best way of implementing opaque (abstract) data types
in C?
---
2.4: How can I implement opaque (abstract) data types in C?
==========
A: No. There is no single, good way for a compiler to implement
implicit structure comparison (i.e. to support the == operator
---
A: No. There is not a good way for a compiler to implement
structure comparison (i.e. to support the == operator
for structures) which is consistent with C's low-level flavor.
==========
A simple byte-by-byte comparison could founder on random bits
present in unused "holes" in the structure (such padding is used
to keep the alignment of later fields correct; see question 2.12).
---
present in unused "holes" in the structure (see question 2.12).
==========
Note also that if the structure contains any pointers, only
---
Also, if the structure contains any pointers, only
the pointer values will be written, and they are most unlikely
to be valid when read back in.
==========
Finally, note that for widespread portability you must use the
"b" flag when fopening the files; see question 12.38.
---
"b" flag when opening the files; see question 12.38.
==========
A: Structures may have this padding (as well as internal padding),
if necessary, to ensure that alignment properties will be
preserved when an array of contiguous structures is allocated.
Even when the structure is not part of an array, the end padding
---
A: Padding at the end of a structure may be necessary to preserve
alignment when an array of contiguous structures is allocated.
Even when the structure is not part of an array, the padding
remains, so that sizeof can always return a consistent size.
==========
A: At the present time, there is little difference. The C Standard
---
A: There is little difference. The C Standard
says that enumerations may be freely intermixed with other
integral types, without errors.
==========
that they obey block scope. (A compiler may also generate
nonfatal warnings when enumerations and integers are
indiscriminately mixed, since doing so can still be considered
bad style even though it is not strictly illegal.)
---
nonfatal warnings when enumerations are indiscriminately mixed,
since doing so can still be considered bad style.)
==========
(Loosely speaking, by "multiple, ambiguous side effects" we mean
any combination of ++, --, =, +=, -=, etc. in a single expression
---
any combination of increment, decrement, and assignment operators
in a single expression which causes the same object either to be
modified twice or modified and then inspected.
==========
Note that (long int)(a * b) would *not* have the desired effect.
---
Notice that (long int)(a * b) would *not* have the desired
effect.
==========
or a delibrate but nonstandard extension if a particular
---
or a deliberate but nonstandard extension if a particular
==========
Whenever possible, you should choose appropriate pointer types
in the first place, instead of trying to treat one type
---
When possible, however, you should choose appropriate pointer
types in the first place, rather than trying to treat one type
as another.
==========
void * acts as a generic pointer only because conversions are
---
void * acts as a generic pointer only because conversions (if
necessary) are applied automatically when other pointer types
are assigned to and from void *'s;
==========
4.12: I've seen different methods used for calling functions via
---
4.12: I've seen different syntax used for calling functions via
pointers. What's the story?
==========
pointers, and that "real" function names always decay implicitly
into pointers (in expressions, as they do in initializations;
see question 1.34). This reasoning (which is in fact used in
the ANSI standard) means that
---
see question 1.34). This reasoning means that
==========
function pointer followed by an argument list except call the
function pointed to.) An explicit * is still allowed.
---
function pointed to.)
==========
The ANSI C Standard essentially adopts the latter
interpretation, meaning that the explicit * is not required,
though it is still allowed.
==========
5.4: What is NULL and how is it #defined?
---
5.4: What is NULL and how is it defined?
==========
preprocessor macro NULL is #defined (by stdio.h and several
other headers) with the value 0, possibly cast to (void *)
---
preprocessor macro NULL is defined (by stdio.h and several
other headers) as a null pointer constant, typically 0 or
((void *)0)
==========
NULL should *only* be used for pointers; see question 5.9.
---
NULL should be used *only* as a pointer constant; see question 5.9.
==========
A: Not in general. The complication is that there are machines
---
A: Not in the most general case. The complication is that there
are machines which use different internal representations for
pointers to different types of data.
==========
pointer arguments of other types would still be problematical,
---
pointer arguments of other types could still (in the absence
of prototypes) be problematical,
==========
This article uses the phrase "null pointer" (in lower case) for
sense 1, the character "0" or the phrase "null pointer constant"
---
sense 1, the token "0" or the phrase "null pointer constant"
for sense 3, and the capitalized word "NULL" for sense 4.
==========
A: C programmers traditionally like to know more than they might
need to about the underlying machine implementation.
---
A: C programmers traditionally like to know a lot (perhaps more
than they need to) about the underlying machine implementation.
==========
integer zero instead of an error message, and if that uncast 0
was supposed to be a null pointer constant, the code may not
work.
---
was supposed to be a null pointer constant, the resulting
program may not work.
==========
Some 64-bit Cray machines represent int * in the lower 48 bits
of a word; char * additionally uses the upper 16 bits to
---
of a word; char * additionally uses some of the upper 16 bits to
indicate a byte address within a word.
==========
A: This message, which typically occurs with MS-DOS compilers, means
that you've written, via a null (perhaps because uninitialized)
pointer, to an invalid location (probably offset 0 in the
default data segment).
---
means that you've written, via a null pointer, to an invalid
location -- probably offset 0 in the default data segment.
==========
A: In one source file you defind an array of characters and in the
---
A: In one source file you defined an array of characters and in the
==========
It is important to realize that a reference like x[3] generates
---
It is useful to realize that a reference like x[3] generates
different code depending on whether x is an array or a pointer.
==========
If you can't use C9X or gcc, you'll have to use malloc(), and
---
If you can't use C99 or gcc, you'll have to use malloc(), and
remember to call free() before the function returns.
==========
Finally, in C9X you can use a variable-length array.
---
Finally, in C99 you can use a variable-length array.
==========
A: The rule (see question 6.3) by which arrays decay into pointers
is not applied recursively.
---
is *not* applied recursively.
==========
not provide an automatically-managed string type. C compilers
only allocate memory for objects explicitly mentioned in the
---
allocate memory only for objects explicitly mentioned in the
source code (in the case of strings, this includes character
==========
A: You got lucky, I guess. The memory pointed to by the
unitialized pointer p happened to be writable by you,
---
A: You got lucky, I guess. The memory randomly pointed to by
the uninitialized pointer p happened to be writable by you,
==========
A pointer value which has been freed is, strictly speaking,
invalid, and *any* use of it, even if is not dereferenced,
---
invalid, and *any* use of it, even if it is not dereferenced,
can theoretically lead to trouble,
==========
A: In C, characters are represented by small integers corresponding
to their values (in the machine's character set), so you
---
to their values in the machine's character set. Therefore, you
don't need a conversion function: if you have the character, you
have its value.
==========
DEBUG("i = %d" _ i)
---
DEBUG("i = %d" _ i);
==========
controversial trigraph sequences). The ANSI C standard also
formalizes the C run-time library support routines.
---
formalized the C run-time library support routines.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment