OSDev.org

Next week going to attend C aps. Could somebody post some C aps questions (with answers and explanations). Something that you find interesting and odd.
Let me be first. May be its known to everyone.
main()
{
printf("Hello","World");
printf("Hello""World");
}
HelloHelloWorld

"Interesting and odd" is in the eye of the beholder.

As for your example:
[tt]printf()[/tt] prints 0..n arguments under control of the format string passed as first argument. Arguments are converted to output using "conversion specifiers", which might be as simple as "%d" (print a decimal integer) and as complex as "%+12.6e" (print a floating point in exponent notation, right-aligned in a 12-char field, with a precision of 6 and a leading plus sign if not negative).

Your format string "Hello" does not contain any conversion specifier, resulting in the argument "World" being ignored.

As for the second, string constants are concatenated.

Sorry that I don't come up with somethign "strange" myself, but the "strangeness" that I do find lurks in the depths of C++ and linkers.

if _that_ confuses you, then what would it be with which does print ... "six"
and will likely to issue a warning, such as your ("hello", "world") will.

or even which does print ... 42 (that one is on wikipedia )

Pype.Clicker wrote: ...and will likely to issue a warning, such as your ("hello", "world") will.

If you run [tt]gcc -Wall[/tt]. If you don't use [tt]-Wall[/tt], don't use GCC.

@Pype: That's exactly why one is advised to always put brackets around #define'd statements that are longer than a single expression.

cheers Joe

Adding numbers to pointers always confuses me. ptr points to the value: 0x14
a contains the value: 0x11

C89 or C99?
What does this code print?

Candy wrote: C89 or C99?

Code: Select all

int value = 42 + 12 //* divisor */ 3
   + 4;

What does this code print?

Not a damn thing

However, if you meant "what would [tt]value[/tt] be after this assignment", then AFAIK the answer would be 58. Since the tokenizing rules for C and C++ (and ingrained in LEX and its descendants) follow the principle of 'continue to the largest possible token', the '//' after the 12 would be interpreted as a line comment, so everything else on that line is ignored.

...but in C89 there is no such thing as a line comment, so it would be (42 + 12 / 3 + 4) = 50...

Solar wrote: ...but in C89 there is no such thing as a line comment, so it would be (42 + 12 / 3 + 4) = 50...

Which is exactly my point. If you compile this with a C99-capable compiler (tested with GCC), it won't complain and produce 58. If you compile this with a non-C99 capable compiler (didn't test) you should get 50, again without warning.

Now that's a bug.

Not a bug, two different languages. Now don't get me started about the stunts I will have to pull off in PDCLib to enable C89 / C99 compliance with a single flick of a switch... new printf / scanf converters, some subtle changes in semantics (like the % operator)...

@ pype: certainly i am not confused with that thing. Just want to show an example.
But once again you people proved your skill by talking about compiler compliance, c89, c99 etc. I am not expected to know abt c89, c99 etc such stuff by recruitment peoples in our campus. Just the basics.

Well, you better know that stuff when you start working on source in earnest. It's not some arcane knowledge to show of with on some internet forum, it's the medication for "strange errors headache"... ;D

Solar wrote: Not a bug, two different languages. Now don't get me started about the stunts I will have to pull off in PDCLib to enable C89 / C99 compliance with a single flick of a switch... new printf / scanf converters, some subtle changes in semantics (like the % operator)...

It's a "bug" of sorts in the newer compiler not to warn for the construct, because it's detectable and causes stuff not to port clearly from C89 to C99.

Are there any (modern) compilers using C89?

From what you say I assume gcc (and any windows port of that) is using C99, is that correct?