Q: Which range corresponds to long double on Turbo C under 16-bit DOS (extended-precision format)? Choose the option that matches the typical 80-bit extended range.

Introduction: Older Turbo C compilers on 16-bit DOS used the x87 extended-precision format for long double. This question checks recognition of its characteristic magnitude range. Given Data / Assumptions: Platform: Turbo C on 16-bit DOS Type: long double (extended precision) Focus: approximate exponent limits Concept / Approach: The x87 80-bit extended format offers roughly 64 bits of significand precision and a very wide exponent range. Typical documented magnitude limits for long double in that environment are about 3.4E-4932 (min positive normalized) to about 1.1E+4932 (max). Step-by-Step Solution: 1) Recall extended-precision exponent range around ±4932 in base 10.2) Note that min and max are not symmetric because of significand normalization and representation.3) Among the given choices, 3.4E-4932 to 1.1E+4932 matches the common documentation. Verification / Alternative check: Consult classic Turbo C reference tables or LDBL_MAX and related macros in headers for that toolchain; they align with the selected range. Why Other Options Are Wrong: 3.4E-4932 to 3.4E+4932: upper bound is too small.1.1E-4932 to 1.1E+4932: lower bound format is inconsistent with typical documentation.1.7E-4932 to 1.7E+4932: values do not correspond to standard references. Common Pitfalls: Confusing modern compilers' long double (which can be 80-bit, 64-bit, or 128-bit depending on platform) with historical Turbo C behavior. Always verify against the specific toolchain. Final Answer: 3.4E-4932 to 1.1E+4932

Q: A float occupies 4 bytes. If the hexadecimal values of these 4 bytes are A, B, C, and D, in what order are they stored in memory? Consider hardware endianness when determining byte order.

Introduction: Byte order in memory is determined by the machine's endianness, not by the C type (float) itself. The question evaluates awareness of big-endian versus little-endian storage conventions. Given Data / Assumptions: Type size: 4 bytes Per-byte hex values labeled A, B, C, D Unknown CPU endianness Concept / Approach: Big-endian systems store the most significant byte at the lowest address (ABCD), while little-endian systems store the least significant byte first (DCBA) for a 4-byte value. C does not mandate endianness; it is implementation- and hardware-defined. Step-by-Step Solution: 1) Identify that endianness is a property of the platform.2) Recognize that both ABCD and DCBA are possible depending on the machine.3) Therefore, without specifying architecture, the only correct general answer is: it depends. Verification / Alternative check: On a system, inspect memory through a byte pointer cast or use utilities to print addresses and byte contents of a known value to observe actual order. Why Other Options Are Wrong: ABCD: assumes big-endian only.DCBA: assumes little-endian only.0xABCD: represents a halfword-style literal; not a 4-byte byte-order description. Common Pitfalls: Assuming a universal order based on experience with one architecture (e.g., x86 little-endian). Portable code should not depend on a particular endianness unless documented. Final Answer: Depends on big endian or little endian architecture

Question 1

C programming and IEEE-754 float on little-endian (Intel) The binary equivalent of 5.375 in normalized IEEE-754 single-precision form is: 0100 0000 1010 1100 0000 0000 0000 0000 Given the following C program, what output bytes (one per line, hex, le…

Accepted Answer

Introduction / Context: In C programming, the in-memory representation of floating-point numbers follows the IEEE-754 standard (for typical desktop compilers), and the byte order depends on the machine's endianness. Intel architectures are little-endian, meaning the least significant byte is stored at the lowest memory address. This question tests your understanding of IEEE-754 single-precision encoding and how pointer-based byte inspection reveals the byte order on Intel systems. Given Data / Assumptions: Value: a = 5.375 (single precision float). IEEE-754 single precision: 1 sign bit, 8 exponent bits, 23 fraction bits. Normalized binary given: 0100 0000 1010 1100 0000 0000 0000 0000. Platform: Intel (little-endian). Code prints p[0], p[1], p[2], p[3] with %02x and a newline after each. Concept / Approach: IEEE-754 single precision encodes 5.375 as sign = 0, exponent = 129, fraction chosen so that 1.01011 * 2^2 = 5.375. In hex, this bit pattern is 0x40AC0000. On a big-endian system, bytes would appear in memory as 40 AC 00 00. On a little-endian system (Intel), the order in memory is reversed at the byte level, so the sequence read through a char* from lowest address becomes 00 00 AC 40. Step-by-Step Solution: 1) Normalize 5.375: 5.375 = 101.011 (binary) = 1.01011 * 2^2. 2) Exponent field = 127 + 2 = 129 = 0x81; with sign = 0. 3) Fraction (mantissa) bits after the leading 1 are 01011 followed by zeros. 4) Full 32-bit pattern = 0x40AC0000 (matches the given binary: 0100 0000 1010 1100 0000 0000 0000 0000). 5) Big-endian byte layout would be: 40 AC 00 00. 6) Intel is little-endian ⇒ in memory the byte order is reversed: 00 00 AC 40. 7) The loop prints p[0], p[1], p[2], p[3] as two-digit lowercase hex, each on a new line ⇒ outputs the sequence 00, 00, ac, 40 (often written as 00 00 AC 40). Verification / Alternative check: Cross-check with a float-to-hex table or by constructing the float: sign 0, exponent 129 (binary 1000 0001), fraction 010 1100 0000 0000 0000 000. Group into nibbles to confirm 0x40AC0000. Reversing byte order for little-endian confirms the printed order 00 00 AC 40. Why Other Options Are Wrong: 40 AC 00 00: This is the big-endian order, not what p[0]..p[3] prints on Intel. 04 CA 00 00: Digits are permuted; exponent and fraction bits no longer match 5.375. 00 00 CA 04: Byte values and order do not correspond to 0x40AC0000 reversed. Common Pitfalls: Confusing value endianness (byte order) with bit order; IEEE-754 bit layout is fixed, but memory byte order can differ by architecture. Assuming printf on a float prints bytes directly; here we explicitly cast the float's address to char* and index bytes. Forgetting that Intel is little-endian, so p[0] is the least significant byte. Final Answer: 00 00 AC 40

Question 2

In C language, how will you treat the constant 3.14 explicitly as a long double literal? Add the correct type suffix to the numeric constant so the compiler stores it as long double.

Accepted Answer

Introduction: In C programming, floating constants can be forced to a particular floating type by adding a suffix. This question checks whether you know the correct suffix to create a long double literal from a decimal number like 3.14. Given Data / Assumptions: Literal: 3.14 Goal: make it a long double Environment: standard C syntax for literal suffixes Concept / Approach: By default, an unsuffixed floating constant such as 3.14 is of type double. C allows suffixes to change the type: 'f' or 'F' yields float, and 'l' or 'L' yields long double. No other multi-letter combinations apply to decimal floating constants. Step-by-Step Solution: 1) Start with the constant 3.14 (type: double by default).2) To request long double, append the uppercase L suffix.3) The resulting token 3.14L is parsed as type long double by the compiler.4) No additional casts are required when the literal itself has the desired type. Verification / Alternative check: You can confirm by using sizeof with the literal in an expression context or by assigning it to a long double variable and observing that no narrowing conversion occurs. Why Other Options Are Wrong: 3.14LD: 'LD' is not a valid suffix; only 'L' is defined for long double.3.14DL: 'DL' is not a recognized suffix pattern.3.14LF: Combining 'L' and 'F' is invalid for decimal floating constants. Common Pitfalls: Using lowercase 'l' can be confused with '1' in some fonts; prefer uppercase 'L' for clarity. Do not add two-letter combinations such as 'LD' expecting them to work; the standard specifies single-letter suffixes. Final Answer: use 3.14L

Question 3

In C language, how will you treat the constant 3.14 explicitly as a float literal? Use the correct single-letter suffix that converts a double literal into a float.

Accepted Answer

Introduction: This question tests how to specify the type of a floating constant directly in source code, ensuring it is compiled as a float rather than the default double. Given Data / Assumptions: Literal: 3.14 Target type: float Language: C, standard literal suffix rules Concept / Approach: Unadorned decimal floating constants are of type double. Appending the suffix 'f' or 'F' makes the literal type float. This avoids implicit conversions when initializing float variables or calling functions expecting float. Step-by-Step Solution: 1) Start with 3.14 (double by default).2) Append the 'f' suffix to get 3.14f, which is type float.3) Use it directly in initializations like: float x = 3.14f; Verification / Alternative check: Use sizeof in a quick test expression or inspect warnings when assigning 3.14 versus 3.14f to a float; the suffixed form avoids promotions or conversions. Why Other Options Are Wrong: float(3.14f): 'float(...)' is not a cast syntax in C; C uses (type)expr. Also unnecessary if the literal already has 'f'.f(3.14): 'f' is not a type or function by default; this is not a suffix.(f)(3.14): 'f' is not a valid typename. Casts must use real types like (float). Common Pitfalls: Forgetting the suffix causes the compiler to treat the literal as double, which may change overload resolution in C++, or cause implicit conversions and warnings in C when assigned to float. Final Answer: use 3.14f

Question 4

In C and computer architecture contexts, what is the binary representation of the decimal number 5.375? Express the integer and fractional parts correctly in base-2 form.

Accepted Answer

Introduction: Converting decimal fractions to binary requires handling the integer and fractional parts separately. This question evaluates understanding of binary conversion for a mixed number (integer plus fraction). Given Data / Assumptions: Decimal number: 5.375 Base required: 2 (binary) No rounding; exact representation is expected. Concept / Approach: Split the number into integer and fractional parts. Convert the integer by repeated division by 2. Convert the fraction by repeated multiplication by 2, collecting integer bits in order. Then combine with a binary point. Step-by-Step Solution: 1) Separate: 5.375 = 5 + 0.375.2) Integer 5 to binary: 5 / 2 = 2 remainder 1; 2 / 2 = 1 remainder 0; 1 / 2 = 0 remainder 1. Reading remainders upward gives 101.3) Fraction 0.375: multiply by 2 repeatedly.0.375 * 2 = 0.75 → bit 00.75 * 2 = 1.5 → bit 1, carry 1, keep fraction 0.50.5 * 2 = 1.0 → bit 1, fraction becomes 0 → stopThus fractional bits are 011.4) Combine: integer 101 and fraction 011 → 101.011. Verification / Alternative check: Convert back: 101.011 = 14 + 02 + 11 + 00.5 + 10.25 + 10.125 = 4 + 0 + 1 + 0 + 0.25 + 0.125 = 5.375, which matches exactly. Why Other Options Are Wrong: 101.101110111: Incorrect fractional bits; evaluates to a different decimal value.101011: Lacks a binary point and mixes integer-only representation; equals 43 decimal.None of above: Incorrect because 101.011 is correct. Common Pitfalls: For fractions, do not divide by 2; instead multiply by 2 and record the integer parts in sequence. Avoid rounding when an exact finite binary exists, as with denominators that are powers of 2 (0.375 = 3/8). Final Answer: 101.011

Question 5

We want to round off a float variable x to the nearest int value in C. Choose the correct, commonly used expression for positive values of x.

Accepted Answer

Introduction: Rounding a floating value to the nearest integer using simple expressions is a common C task. The question focuses on the classic technique suitable for non-negative values of x. Given Data / Assumptions: Variable x is float (or double) and non-negative for this idiom. We desire nearest-integer rounding, not truncation. Standard C casts apply. Concept / Approach: In C, a cast to int truncates toward zero. To emulate rounding to nearest integer for x >= 0, add 0.5 and then truncate. For general cases (including negatives, ties, or banker's rounding), use functions like round, floor, or ceil from math.h, but the simple pattern works for positive x. Step-by-Step Solution: 1) Start with x (assume x >= 0).2) Compute x + 0.5.3) Cast to int: (int)(x + 0.5), which truncates to the integer part, effectively rounding.4) Assign to y. Verification / Alternative check: Example: x = 2.6 → 2.6 + 0.5 = 3.1 → (int)3.1 = 3. For general, prefer y = (int)lround(x) with #include to handle negatives and ties consistently. Why Other Options Are Wrong: y = int(x + 0.5): 'int(...)' is not C cast syntax; C requires (int)(...).y = (int)x + 0.5: adds 0.5 after truncation; result is not an int.y = (int)((int)x + 0.5): truncates first; 2.6 → (int)2.6 = 2 → 2.5 → (int)2.5 = 2, which is wrong for 2.6. Common Pitfalls: For negative x, (int)(x + 0.5) does not round correctly. Use round, lround, or custom logic to handle negatives and tie-breaking rules. Final Answer: y = (int)(x + 0.5)

Question 6

In C, which statement correctly obtains the remainder when dividing the floating values 5.5 by 1.3? Select the standard-library function designed for floating remainders.

Accepted Answer

Introduction: This question checks knowledge of the correct function to compute the remainder of a floating-point division in C. Given Data / Assumptions: Dividend: 5.5 Divisor: 1.3 Language: C with math.h available Concept / Approach: The % operator is defined only for integer operands in C. For floating-point remainders, the standard library provides fmod in math.h, which computes the remainder with the same sign as the dividend according to its specification. Step-by-Step Solution: 1) Include math.h.2) Call fmod: double r = fmod(5.5, 1.3);3) The result r satisfies 5.5 = q * 1.3 + r where q is truncated toward zero and |r| < |1.3|. Verification / Alternative check: You can verify by computing q = trunc(5.5 / 1.3) and then r = 5.5 - q * 1.3 and comparing with fmod's output. Why Other Options Are Wrong: (5.5 % 1.3): % is not defined for floating types.modf(5.5, 1.3): modf splits a float into fractional and integer parts; it does not compute a division remainder.Error: we can't divide: Division is valid; we just need the proper remainder function. Common Pitfalls: Confusing modf with fmod and forgetting to link with the math library on some toolchains. Also watch platform-defined behaviors for negative operands; fmod's remainder sign follows the dividend. Final Answer: rem = fmod(5.5, 1.3)

Question 7

Which range corresponds to long double on Turbo C under 16-bit DOS (extended-precision format)? Choose the option that matches the typical 80-bit extended range.

Accepted Answer

Introduction: Older Turbo C compilers on 16-bit DOS used the x87 extended-precision format for long double. This question checks recognition of its characteristic magnitude range. Given Data / Assumptions: Platform: Turbo C on 16-bit DOS Type: long double (extended precision) Focus: approximate exponent limits Concept / Approach: The x87 80-bit extended format offers roughly 64 bits of significand precision and a very wide exponent range. Typical documented magnitude limits for long double in that environment are about 3.4E-4932 (min positive normalized) to about 1.1E+4932 (max). Step-by-Step Solution: 1) Recall extended-precision exponent range around ±4932 in base 10.2) Note that min and max are not symmetric because of significand normalization and representation.3) Among the given choices, 3.4E-4932 to 1.1E+4932 matches the common documentation. Verification / Alternative check: Consult classic Turbo C reference tables or LDBL_MAX and related macros in headers for that toolchain; they align with the selected range. Why Other Options Are Wrong: 3.4E-4932 to 3.4E+4932: upper bound is too small.1.1E-4932 to 1.1E+4932: lower bound format is inconsistent with typical documentation.1.7E-4932 to 1.7E+4932: values do not correspond to standard references. Common Pitfalls: Confusing modern compilers' long double (which can be 80-bit, 64-bit, or 128-bit depending on platform) with historical Turbo C behavior. Always verify against the specific toolchain. Final Answer: 3.4E-4932 to 1.1E+4932

Question 8

A float occupies 4 bytes. If the hexadecimal values of these 4 bytes are A, B, C, and D, in what order are they stored in memory? Consider hardware endianness when determining byte order.

Accepted Answer

Introduction: Byte order in memory is determined by the machine's endianness, not by the C type (float) itself. The question evaluates awareness of big-endian versus little-endian storage conventions. Given Data / Assumptions: Type size: 4 bytes Per-byte hex values labeled A, B, C, D Unknown CPU endianness Concept / Approach: Big-endian systems store the most significant byte at the lowest address (ABCD), while little-endian systems store the least significant byte first (DCBA) for a 4-byte value. C does not mandate endianness; it is implementation- and hardware-defined. Step-by-Step Solution: 1) Identify that endianness is a property of the platform.2) Recognize that both ABCD and DCBA are possible depending on the machine.3) Therefore, without specifying architecture, the only correct general answer is: it depends. Verification / Alternative check: On a system, inspect memory through a byte pointer cast or use utilities to print addresses and byte contents of a known value to observe actual order. Why Other Options Are Wrong: ABCD: assumes big-endian only.DCBA: assumes little-endian only.0xABCD: represents a halfword-style literal; not a 4-byte byte-order description. Common Pitfalls: Assuming a universal order based on experience with one architecture (e.g., x86 little-endian). Portable code should not depend on a particular endianness unless documented. Final Answer: Depends on big endian or little endian architecture

Question 9

Which header should be added so that the following program using log(36.0) compiles and links correctly? #include<stdio.h> int main() { printf("%f ", log(36.0)); return 0; }

Accepted Answer

Introduction: The function log is part of the C math library. This question checks whether you can identify the correct header needed to declare and use log properly. Given Data / Assumptions: Function used: log(36.0) Output via printf with %f Standard C environment Concept / Approach: In C, mathematical functions such as log, exp, sin, and cos are declared in math.h. Including the proper header ensures correct declarations and types. Some toolchains also require linking with the math library (e.g., -lm) at link time. Step-by-Step Solution: 1) Identify log as a natural logarithm function.2) Recall its declaration resides in math.h.3) Add the line #include to the program.4) If needed by the toolchain, link with the math library, e.g., gcc file.c -lm. Verification / Alternative check: Compile with and without the header to see that the version without math.h yields warnings or errors about implicit declaration or mismatched types. Why Other Options Are Wrong: conio.h: Non-standard header for console I/O on some DOS compilers; unrelated to log.stdlib.h: General utilities (malloc, exit, atoi, etc.), not log.dos.h: Platform-specific DOS functions; not math. Common Pitfalls: Forgetting to link the math library on Unix-like systems. Also, using %f in printf with log is fine because log returns double. Final Answer: #include

Question 10

In standard C, which are the real (floating) data types available? Identify all floating types supported by the language.

Accepted Answer

Introduction: C defines three real (floating) data types for representing non-integer numbers with fractional parts. This question verifies your recall of those precise types. Given Data / Assumptions: Language: C Goal: list floating types Concept / Approach: The C standard specifies three floating types: float, double, and long double. Their exact size and precision can vary by implementation, but these are the canonical floating types and appear in headers, library functions, and type promotions. Step-by-Step Solution: 1) Recall the set of floating types defined by the standard.2) Match the options containing all three and no integers.3) Select: float, double, long double. Verification / Alternative check: Check any C standard reference or compiler documentation; typeof and sizeof show varying sizes but consistent type names across compilers. Why Other Options Are Wrong: float, double: incomplete; missing long double.short int, double, long int: includes integer types; not all are floating.double, long int, float: includes an integer type (long int); set is incorrect. Common Pitfalls: Confusing storage size with type identity. Even if long double maps to double on a platform, the language still defines it as a separate type. Final Answer: float, double, long double

Question 11

Observe the formatted-output behavior in C for a float value. Given:
#include<stdio.h>
int main()
{
 float d = 2.25;
 printf("%e,", d);
 printf("%f,", d);
 printf("%g,", d);
 printf("%lf", d);
 return 0;
}
What is the exact output (spacin…

Accepted Answer

Introduction / Context: This problem checks knowledge of default argument promotions and how printf format specifiers %e, %f, %g, and %lf behave for a float argument passed to printf. Given Data / Assumptions: float d is passed to printf; due to default argument promotions, it is promoted to double. Format specifiers are sequential: %e, %f, %g, %lf. Typical C library behavior where the length modifier l is ignored with %f-style conversions in printf. Concept / Approach: %e prints a floating value in exponential notation with six digits after the decimal by default: “2.250000e+000”. %f prints fixed-point with six digits after the decimal: “2.250000”. %g chooses compact representation (here “2.25”). In printf (unlike scanf), %lf is accepted and treated the same as %f because floats are promoted to double; the l modifier is ignored, so the last output is again “2.250000”. Step-by-Step Solution: %e → 2.250000e+000%f → 2.250000%g → 2.25%lf → 2.250000 (treated as %f in printf) Verification / Alternative check: Test on common C libraries (glibc, MSVCRT). The C standard allows ignoring l for printf’s floating conversions; scanf differs (%f reads float, %lf reads double). Why Other Options Are Wrong: Options with truncated digits or malformed scientific notation ignore printf defaults. “Error” is not correct for a conforming implementation. Common Pitfalls: Confusing printf with scanf rules; expecting %lf to fail; forgetting the six-decimal default precision. Final Answer: 2.250000e+000, 2.250000, 2.25, 2.250000

Question 12

Pointer size question across platforms: Given
#include<stdio.h>
int main()
{
 float p;
 printf("%d
", sizeof(p));
 return 0;
}
What is sizeof(float) typically on 16-bit versus 32-bit compilers?

Accepted Answer

Introduction / Context: This question probes the relationship between pointer size and platform/ABI, not the pointee type. The sizeof operator reports the storage size of the pointer itself. Given Data / Assumptions: Legacy 16-bit “small/medium memory model” compilers commonly use 16-bit near pointers for code/data, hence 2-byte pointers. Typical 32-bit ABIs use 32-bit addresses, hence 4-byte pointers. We are querying sizeof(p) where p is a float*. Concept / Approach: In C, pointer size depends on the target architecture and memory model, not on the pointed-to type. Therefore, sizeof(float*) equals sizeof(void*) on a given platform. Classic DOS 16-bit compilers generally produce 2-byte near pointers, while 32-bit systems use 4-byte pointers. Modern 64-bit ABIs usually use 8-byte pointers (not listed among the choices). Step-by-Step Solution: Declare float *p; compute sizeof(p).On 16-bit model → 2 bytes; on 32-bit model → 4 bytes.Note: This holds regardless of float vs int pointer. Verification / Alternative check: Print sizeof on target systems; observe that all object pointers share the same size within an ABI. Why Other Options Are Wrong: The pointee type does not affect pointer size, making options that swap sizes incorrect. “Always 8” generalizes from 64-bit only and ignores older ABIs. Common Pitfalls: Assuming pointer size equals sizeof(pointee); forgetting that %d for sizeof should be cast to int or printed with %zu for size_t. Final Answer: 2 on a 16-bit compiler, 4 on a 32-bit compiler

Question 13

Floating literal precision comparison in C: given
#include<stdio.h>
int main()
{
 float a = 0.7;
 if(a < 0.7f)
 printf("C
");
 else
 printf("C++
");
 return 0;
}
What will be printed (consider default promotions and literal types)?

Accepted Answer

Introduction / Context: This problem explores floating-point literals, default types, and precision in C. Specifically, it contrasts assigning a double literal to a float versus using an explicit float literal for comparison. Given Data / Assumptions: float a = 0.7; // 0.7 is a double literal, then converted to float on assignment. Comparison uses 0.7f, which is a float literal. IEEE-754 binary floating point commonly used; 0.7 is not exactly representable. Concept / Approach: When assigning 0.7 (double) to a float, the value is rounded to the nearest representable float, typically about 0.699999988. The literal 0.7f is already a float with the same nearest representable value as the converted double under round-to-nearest. Thus, a and 0.7f are equal on typical systems. The test a < 0.7f is false, so the else branch executes and prints “C++”. Step-by-Step Solution: Store a ≈ 0.699999988 (float).Literal 0.7f ≈ 0.699999988 (same float value).Compare: a < 0.7f → false.Execute else branch → print “C++”. Verification / Alternative check: Print with high precision (e.g., printf("%.9f %.9f
", a, 0.7f)) to see equal representations; or compare with == and observe true on common compilers/ABIs. Why Other Options Are Wrong: “C” would require a to be strictly less than 0.7f, which it is not in typical IEEE-754 float. There is no compile error, and behavior is defined for these operations. Common Pitfalls: Assuming decimal literals are exact; forgetting literal default types; mixing float/double without considering rounding and promotions. Final Answer: C++

Question 14

In C programming, consider floating-point comparison:

#include<stdio.h>
int main()
{
 float a = 0.7;
 if (a < 0.7)
 printf("C
");
 else
 printf("C++
");
 return 0;
}

What will be printed, given typical binary floating-point represen…

Accepted Answer

Introduction / Context: This question tests understanding of binary floating-point representation, literal types, and the usual arithmetic conversions that occur in comparisons in C. Small decimal fractions like 0.7 cannot be represented exactly in binary IEEE-754 format, which leads to subtle comparison results. Given Data / Assumptions: Variable a is declared as float and initialized with the decimal literal 0.7. The literal 0.7 has type double in C unless suffixed; thus the expression a < 0.7 promotes a to double before the comparison. printf prints either "C" or "C++" followed by a newline. Concept / Approach: Binary floating-point cannot exactly encode most decimal fractions. The float value stored in a is typically slightly less than 0.7 when rounded to 24-bit float precision. During the comparison, a is promoted to double and compared with the double literal 0.7, which is represented with about 53 bits of precision and is slightly different from the rounded float value. Step-by-Step Solution: Store a = (float)0.7 → value becomes approximately 0.69999999...Compare as double: (double)a ≈ 0.69999999... versus 0.7 (double).Since 0.69999999... < 0.7 is true, the if branch executes.printf prints "C". Verification / Alternative check: If we force both sides to float (e.g., compare a with 0.7f), many compilers still yield a slightly smaller value for a than 0.7f; result remains true. If we assign double a2 = 0.7 and compare a2 < 0.7, the result is false. Why Other Options Are Wrong: C++: would require a to be ≥ 0.7, which is not the case with typical float rounding.Compiler error: the program is valid standard C.None of the above: not applicable since "C" matches the behavior. Common Pitfalls: Assuming decimal literals are exact; forgetting that 0.7 is double; assuming float values compare equal to their decimal literals. Final Answer: C

Question 15

In C with math.h included, what does this program print? #include #include int main() { printf("%f ", sqrt(36.0)); return 0; } Assume typical IEEE-754 and default printf formatting for %f.

Accepted Answer

Introduction / Context: This tests knowledge of sqrt from math.h and default floating-point formatting in printf. In C, %f prints a double value with six digits after the decimal by default. Given Data / Assumptions: sqrt(36.0) returns the principal square root as a double. printf with "%f" prints six fractional digits unless precision is specified otherwise. Headers are included correctly to provide prototypes. Concept / Approach: Compute sqrt(36.0) then format the result using "%f". No integer formatting or rounding tricks are involved; it is a direct call and a direct print. Step-by-Step Solution: Evaluate sqrt(36.0) → 6.0 (double).printf("%f", 6.0) → "6.000000". Verification / Alternative check: Changing the format to "%.1f" would print "6.0". Using "%g" would typically print "6". Why Other Options Are Wrong: "6.0" or "6": do not match the exact formatting of %f with default precision.Error: math.h is included; no prototype error occurs. Common Pitfalls: Confusing %f (fixed six decimals) with %g or custom precisions. Final Answer: 6.000000

Question 16

On a typical platform where sizeof(float)=4, sizeof(double)=8, and sizeof(long double)=12, what does this program print? #include #include int main() { printf("%d, %d, %d ", sizeof(3.14f), sizeof(3.14), sizeof(3.14l)); re…

Accepted Answer

Introduction / Context: This question focuses on literal suffixes and type sizes. In C, 3.14f is float, 3.14 is double, and 3.14l (or 3.14L) is long double. The exact size of long double is implementation-defined. Given Data / Assumptions: Assumed platform: float=4 bytes, double=8 bytes, long double=12 bytes (common on some 32-bit x86 ABIs using 80-bit extended precision stored in 12 bytes). printf uses %d; sizeof yields type size in bytes as size_t but will fit typical %d for these small values in practice. Concept / Approach: Map each literal to its type via the suffix and then to its size: f → float, none → double, l/L → long double. Step-by-Step Solution: sizeof(3.14f) → sizeof(float) → 4.sizeof(3.14) → sizeof(double) → 8.sizeof(3.14l) → sizeof(long double) → 12 on the assumed platform. Verification / Alternative check: On other platforms (notably many 64-bit Linux systems), long double can be 16 bytes. On MSVC, long double may equal double (8 bytes). The question specifies the 12-byte assumption to avoid ambiguity. Why Other Options Are Wrong: 4,4,4 and 4,8,8 ignore the long double difference.4,8,10 is not a typical size tuple for standard ABIs. Common Pitfalls: Forgetting literal suffixes or assuming sizes are universal across compilers and architectures. Final Answer: 4, 8, 12

Question 17

With math.h functions, what is the output of this code? #include #include int main() { float n = 1.54; printf("%f, %f ", ceil(n), floor(n)); return 0; } Assume default %f precision.

Accepted Answer

Introduction / Context: ceil returns the least integer value greater than or equal to the argument; floor returns the greatest integer value less than or equal to the argument. Both return double. Given Data / Assumptions: n = 1.54. ceil(1.54) = 2.0, floor(1.54) = 1.0. printf uses "%f" for both values, printing six fractional digits. Concept / Approach: Apply the definitions directly and print with fixed default precision. Step-by-Step Solution: Compute ceil(1.54) → 2.0.Compute floor(1.54) → 1.0.printf("%f, %f") prints "2.000000, 1.000000". Verification / Alternative check: Using integer casts would truncate toward zero, which also yields 1 for positive 1.54, but cast is not the same as floor for negative values. Why Other Options Are Wrong: Other numeric pairs do not match the mathematical definition of ceil and floor for 1.54. Common Pitfalls: Confusing truncation with floor for negative inputs; forgetting both functions return double. Final Answer: 2.000000, 1.000000

Question 18

Given a float f = 43.20, what do these printf conversions produce?

#include<stdio.h>
int main()
{
 float f = 43.20;
 printf("%e, ", f);
 printf("%f, ", f);
 printf("%g", f);
 return 0;
}

Assume typical IEEE-754 and default precisions f…

Accepted Answer

Introduction / Context: The format specifiers %e, %f, and %g print floating-point values differently. Understanding each specifier and the effect of binary rounding explains the exact output. Given Data / Assumptions: %e prints in exponential notation with six fractional digits by default. %f prints fixed-point with six fractional digits by default. %g chooses either %f or %e in a compact form, trimming trailing zeros. float values are promoted to double when passed to printf. Concept / Approach: Compute how each format represents 43.20. Due to binary rounding, the closest representable float near 43.20 may be slightly larger than 43.2, leading to 43.200001 with %f. Step-by-Step Solution: %e → "4.320000e+01".%f → prints six decimals → "43.200001" on many systems because 43.20 is not exactly representable in binary.%g → compact form → "43.2". Verification / Alternative check: Printing with higher precision (e.g., "%.9f") will reveal the tiny rounding difference more clearly. Why Other Options Are Wrong: They contain impossible suffixes (like "f" in output) or arbitrary rounding that does not match default printf behavior. Common Pitfalls: Expecting %f to always show exactly the decimal literal; forgetting argument promotion of float to double in variadic functions. Final Answer: 4.320000e+01, 43.200001, 43.2

Question 19

What is printed after casting a float to int in C?

#include<stdio.h>
int main()
{
 float fval = 7.29;
 printf("%d
", (int)fval);
 return 0;
}

Assume standard C semantics for casts and printf.

Accepted Answer

Introduction / Context: Casting from float to int truncates toward zero. Printing with %d expects an int value. This question checks understanding of truncation versus rounding. Given Data / Assumptions: fval = 7.29 (positive float). (int)fval discards the fractional part. printf("%d") prints the resulting integer in decimal. Concept / Approach: Use the truncation rule: for positive numbers, truncation is equivalent to floor; for negative numbers, truncation differs from floor. Step-by-Step Solution: Compute (int)7.29 → 7.printf prints 7. Verification / Alternative check: Testing with a negative value, e.g., (int)(-7.29) would yield -7 (truncation), whereas floor(-7.29) would be -8. Why Other Options Are Wrong: 0, 0.0, 7.0: not consistent with truncation and %d formatting. Common Pitfalls: Confusing rounding with truncation; using the wrong printf format specifier. Final Answer: 7

Floating Point Issues Questions