So you think you know C?

https://hackernoon.com/so-you-think-you-know-c-8d4e2cd6f6a6

by thewisenerd • 10 years ago

309 198 10 years ago

TillE• 10 years ago

The lack of specified type sizes is something that bit me recently. On pretty much every x86-64 C/C++ compiler, sizeof(long) is 8, except on MSVC where it's 4. Thank goodness for explicitly sized, now-standard types like int64_t.

tptacek3• 10 years ago

They're standardized now, but they've been in universal use since before I started writing C in 1994.

Jtsummers4• 10 years ago

I wish they were in universal use. I'm constantly cleaning up a colleagues code where he's made many (now incorrect) assumptions about what "int", "short", "long" would mean. Even pointing him to the standard didn't help, I just got back his stock answer, "It works on X so why do we need to worry?" To which I reply, "Because we've changed architectures and compilers since then and now your code is frequently broken." You'd think he'd learn after a while, but some people are too stubborn.

pjmlp8• 10 years ago

I surely don't remember using them while creating code across MS-DOS, Xenix, DG-UX, Windows 3.1, just constraining myself to the compilation targets I used in 1994.

marcosdumay2• 10 years ago

sizeof(long) >= 4

sizeof(int) >= 2

sizeof(long) >= sizeof(int)

That's all you can expect.

klodolph• 10 years ago

You literally cannot expect the first two. On word-addressable hardware, you could easily get sizeof(long) = sizeof(int) = 1. This happens on DSPs.

vortico2• 10 years ago

I understand some implementations might break this rule, but what standard states this?

loeg7• 10 years ago

Also long long >= 8, per C99.

krylon2• 10 years ago

To me, stdint.h was quite possibly the best thing about C99.

peapicker• 10 years ago

IBMi (OS/400) sizeof long is also 4 by default.

Not really "64 bit" tho-on IBMi pointers are 16 bytes with teraspace enabled.

tptacek3• 10 years ago

This is pretty silly. Being fluent in C has not much at all to do with language quirks. Since (I assume) the 1980s, the comp.lang.c crowd has been reminding us that compilers are fundamentally unknowable and that sizeof(char) could very well be a random walk averaging 1.35. Meanwhile, in the real world, network and kernel programmers have been using some variant of u_int32_t since forever to ensure that they can parse network packets and driver data structures by copying or even casting things into structs.

Also, why would anyone write ' ' * 13? For most of these questions, if your first instinct is "that doesn't look like good C code", your answer is better than the "right" answer.

paxcoder2• 10 years ago

Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

However, "it's implementation specific and it's most probably this, or that if you use such and such a compiler flag" is different from "I don't know".

As a rule of thumb, don't assume things about C's abstractions, read the standard instead, or ask friendly humans who do if they check out.

ohyoutravel• 10 years ago

Is this true? I thought the C99 standard just specified that the guaranteed minimum size is 1 byte. I've been using CHAR_BIT to define this.

jsjohnst• 10 years ago

Exactly. I immediately thought "implementation specific" on the first question but then didn't see that as an option. By the second question, I had caught on that 'D' was the intended answer throughout.

breadbox3• 10 years ago

Minor point: sizeof(char) was defined to be 1 even in the original C89. "char" has always been a misspelling of "byte" in C.

jcoffland3• 10 years ago

Better yet, write a test program and check the answer yourself.

greenshackle2• 10 years ago

read the standard

Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.

(Not that you should take his word as gospel, I don't fully agree myself, but it's worth considering.)

gens2• 10 years ago

Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

(edit: i misread, it's always 1) To be pedantic, a size of char is defined by CHAR_BIT in limits.h. As well as all of the min and max values and lengths in bits for integers.

To add to the discussion, many high level languages don't have a hard min and max values (haskell, that is popular in these woods, i see has minBound/maxBound).

From the "So you think you know C?" test i answered... probably correct for the "standard" x86 implementation, while knowing that they are implementation specific (for 4 i'm not sure). The authors "Don't know" is his own, i would have answered the questions as "It depends", but that was not offered.

In the end i agree with the general notion here, that this is ugly C.

PS Integer wrapping is undefined as well, so "good" C code should work around it. (i miss this from assembly)

yes_or_gnome• 10 years ago

Yes, but the term "byte" doesn't tell you much. Most people assume that a byte is 8-bits which isn't true. If the definition the of `char` was `1 octet`, then you could make safer assumptions about "What's the result of `' ' * 13`?".

From ISO/IEC 9899:2011:

  3.6

  byte

  addressable unit of data storage large enough to hold any
  member of the basic character set of the execution
  environment

  NOTE 1 It is possible to express the address of each
  individual byte of an object uniquely.

  NOTE 2 A byte is composed of a contiguous sequence of bits,
  the number of which is implementation-defined. The least 
  significant bit is called the low-order bit; the most
  significant bit is called the high-order bit.

Edit: Reading further into the C11 spec, `5.2.4.2.1 Sizes of integer types <limits.h>`, it says that `CHAR_BIT` must be 8 bits (or larger). A google search suggests there exists some processors that have 16-bit bytes and others that have 32-bit bytes.

namename• 10 years ago

yeah

krylon2• 10 years ago

Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

Ever since, reading introductions to C that say things like "a char is usually one byte in size" make me cringe. I never bothered to check, though, what C89/C90 had to say on this.

qntty• 10 years ago

Is the slanted apostrophe symbol ( ‘ ) that he uses in #3 even treated the same as the normal single quote ( ' ) in C? Note that it's not even a backtick ( ` ), it's a third symbol that's not on a keyboard.

adregan• 10 years ago

That may be a typo. Macs have a feature that automatically converts ' and " into ‘ and “ called "smart quotes." It's innocuous most of the time and maybe even welcome, but can be a real pain when trying to share a command with someone (who is probably going to copy and paste it, receive an error and not know why).

pcwalton• 10 years ago

Meanwhile, in the real world, network and kernel programmers have been using some variant of u_int32_t since forever to ensure that they can parse network packets and driver data structures by copying or even casting things into structs.

And compiler developers in the real world are also increasingly nervous at this state of affairs. The subset of C that works in practice is unspecified. There are plenty of optimizations that compiler developers would like to do, but they don't because they're worried about breaking some code somewhere that relies on undefined behavior (like the code you're talking about). At the same time, performance competition pushes compilers to exploit undefined behavior more and more heavily. There is (IMHO, well-founded) worry across the board that this situation is not sustainable. Experience with this problem motivated the design of languages like Swift, which try to clamp down on UB drastically—which also has the happy side effect of making articles like this one inapplicable.

Undefined behavior has already had practical consequences, such as security-sensitive VM escapes: https://bugs.chromium.org/p/nativeclient/issues/detail?id=24...

tedunangst2• 10 years ago

Isn't that code wrong anyway? If the bundle size were 16 bytes, the shift would be well defined but still give the wrong result, 64K alignment. Not a great example of undefined behavior causing a bug.

eveningcoffee2• 10 years ago

After reading some of the comments below the article, I think that takeaway is that C is less portable than you may believe.

dimman• 10 years ago

No not really, you just have to program it in a portable way hence knowing this stuff is important. Big difference.

pjmlp8• 10 years ago

I guess you don't spend too much time looking at the typical C code written on most average enterprise shops.

Back when I used to code C professionally on early 2000's, these type of issues were quite common.

Specially since regardless of what one reads on HN, or hears at most conferences, most of those companies, which tend to see IT as a cost center, usually don't employ any processes regarding code reviews, static analysis or unit tests.

Which in languages like C this means an heavy price when things blow up, or the way things are going with IoT.

So given the increase in CVE entries, this still matters a lot.

chetanahuja3• 10 years ago

"I guess you don't spend too much time looking at the typical C code written on most average enterprise shops"

The list of qualifiers and disclaimers in that sentence made me dizzier than taking that quiz on dark corners of C.

yitchelle2• 10 years ago

I think that this might be true in the early 2000's, I hope that we have moved on significantly by now. I know that the automotive folks are getting a lot better at code review, static analysis and unit testing.

roel_v2• 10 years ago

The problem with all these language lawyets is thay they present themselves as the keepers of the Truth and if you can't cite the standard for every line of code you write, you "don't really know the language." While in reality, language lawyering is an obscure hobby, almost orthogonal to real world programming.

mark-r3• 10 years ago

Except in this case the OP presented a situation where it really made an actual difference.

0xAA55• 10 years ago

Or you could just not worry about it and assume the language is well-defined with precise methodologies grounded on common sense like Ada.

https://gcc.gnu.org/onlinedocs/gnat_rm/Value_005fSize-and-Ob...

On second thought, who cares about reading its for squares and nerds. I would rather spend 2 hours Google searching what is an octet and finding out how enums are represented... :p

antirez• 10 years ago

Yes, and corollary: you'll find people that have memorized the C standard and can answer the more subtle questions which are actually unable to use the language to create a decently sized program.

hal9000xp• 10 years ago

In 2008, I've started to learn C language by solving these amazing puzzles:

http://www.gowrikumar.com/c/index.php

I think this page contains high quality C puzzles.

If you know something similar, let me know, I would love to solve.

kristianp• 10 years ago

I used to enjoy these:

http://www.gimpel.com/html/bugs.htm

BTW (apologies), the correct past-tense is "In 2008, I started to learn the C...".

pksadiq5• 10 years ago

A note: 'int main()' and 'int main(void)' are different in C (but the same in C++).

Most online puzzles uses the former (I have also seen this in hacker rank), but the standard says that the main function should be defined as void if no argument is accepted (or some implementation defined manner)

72deluxe• 10 years ago

Yep, we write C++ at work and the technical director loves writing (void) in parameters due to years of habit after writing C. To me it looks redundant (I went straight to C++, skipped C).

maxxxxx• 10 years ago

This is a good reminder that once you deal with different compilers and operating systems a lot of assumptions don't work anymore.

cjensen3• 10 years ago

Real world things in C that may bite you:

(a) char may be signed or unsigned so

  char a, b;
  ...
  short c = (short (a) << 8 | b);

will not work to construct a 16-bit value from two 8-bit values.

(b) NULL is not a useful macro. For example,

  printf ("%p", NULL);

can have unexpected results.

Those things mentioned in the article? Outside of DSPs and GPUs, you can ignore them.

problems• 10 years ago

Yup, I deal with the unsigned char issue at work all the time, I've got a pile of code with casts to unsigned all over the place due to decoding some legacy data formats. I'm not sure what the cleanest way to fix it is, but I find myself writing nasty stuff like:

    (((short)((unsigned char)a)) << 8)

Which works but goddamn is it ever hard to read. Bracket highlighting makes it just bearable. Fortunately I've abstracted this kind of stuff out as much as possible so I only have it in a few places, but it still bites me in the ass sometimes. Curious if anyone has a cleaner way of expressing this?

cjensen3• 10 years ago

Definitely use the new stdint.h types[1]. That will make your intent a lot clearer. Also consider creating some macros for all common operations (like creating a uint32_t out of four uint8_t).

[1] http://en.cppreference.com/w/c/types/integer

loeg7• 10 years ago

b) NULL is not a useful macro. For example, printf ("%p", NULL); can have unexpected results.

How do you figure?

cjensen3• 10 years ago

According to the fine standard, an implementation may #define NULL as either

  #define NULL ((void *) 0)

or just plain

  #define NULL 0

The latter works correctly because a literal 0 in pointer context is interpreted by the compiler as a null pointer.

If it is 0, the printf() provides no pointer context, so the 0 is interpreted as an int. That works... poorly if sizeof (int) < sizeof (void *)

dep_b• 10 years ago

And I had to learn it the hard way too.

I'm worried. What blew up?

vortico2• 10 years ago

Well, the author is a Ukrainian nuclear engineer. ~

wyldfire• 10 years ago

IMO the real answer is to validate any assumptions by using UBSan wherever possible. Many compilers and many targets are supported.

Even if by some chance half of your C team knows all of the ins and outs, subtle things like this can slip by even when under review.

netule• 10 years ago

This reminds me of a presentation called "Deep C (and C++)" (2011): http://www.slideshare.net/olvemaudal/deep-c/

Nadya• 10 years ago

I was about to post something similar, CTLR+F and found this post. :)

"Deep C" illustrates the difference well between people who know C and people who know C. A bit of it is language lawyering, but some of it can be practical - although perhaps specific to certain projects or environments.

IMO this sort of knowledge is most practical if you're maintaining legacy software or in specific environments that you would otherwise be making a mistake in. People writing evergreen software or in specific targeted environments don't really need to worry about all these types of "Gotch'ya!".

posterboy• 10 years ago

Took me a while to notice the pun, I had to get back to say I like the subtlety.

dxhdr• 10 years ago

I don't understand this critique of an outdated version of the language. Let's see questions written in C99 using stdint types. Dealing with integer widths is a non-issue.

Yes, inc/dec operators take extra care. Structure packing requires platform awareness, similar to how endianness can matter for data manipulation.

kosma3• 10 years ago

Unfortunately licenses for outdated versions of outdated compilers for outdated versions of an ancient language still sell for 3995€ a seat - I know because I'm using one right now. Nothing beats good old 8051 in terms of price. :)

faragon• 10 years ago

C is beautiful.

kosma3• 10 years ago

I did this test as a break from sitting in front of Keil C51. These questions highlight a very important issue: there are platforms and compilers out there that will bite you in the ass if you try to unconsciously apply what you learned while using gcc.

Under Keil C51, alignment is always 1. This is legal C.

Under Keil C51, int is 16-bit. This is legal C.

Under Keil C51, sizeof(pointer) is anything from 1 to 3. This is an extension, but a very popular one.

Don't assume that just because you can write crash-free code on x86, you "know" C.

zokier• 10 years ago

Under Keil C51, sizeof(pointer) is anything from 1 to 3. This is an extension, but a very popular one

I think this is the funniest thing in this all. You might cross all your t's and dot your i's, and you still may trip in a pitfall when your compiler/platform vendor happens to actually diverge from the standard. Such is life with decades old language with at least as many implementations.

kosma3• 10 years ago

Such is the price of using C on Harvard machines. It's even more pronounced on '51 as even the smallest $.5 chip has four (!) different address spaces (direct/register ram, indirect ram, xram and code) - and bigger chips have even more as they support memory banking. The real question is: why doesn't C support Harvard architecture natively, without ugly hacks?

gue5t• 10 years ago

It's been years and I still have nightmares about using Keil toolchains.

gridspy2• 10 years ago

And yet they are far better than the Modula II 8051 compiler we used to use. At least Keil C51 does static analysis on function locals to overlay them and create a "stack."

We used to do that by hand.

userbinator• 10 years ago

int is 16-bit. This is legal C

For x86 in 16-bit realmode (i.e. when you're targeting PCs on MS-DOS), that is also true. Likewise, pointers can be 2 or 4 bytes.

On the other hand, if you are working with such an "exotic" (i.e. not ILP32/LLP64/LP64) platform, you probably already realise that a lot of other things are also very different and the fact that the syntax looks much the same and it's still called "C" is the least of your worries.

Microchip's PIC microcontrollers also come to mind as being an architecture with a C compiler, yet with very different characteristics from the "usual" x86/ARM. (AVRs, Z80s, and the like are more similar to 16-bit x86 restricted to a single segment, a "SIP16" data model.)

Gibbon1• 10 years ago

With gcc on an AVR an int is 16 bits and alignment is 1 as well.

That said I ported a bunch of stuff from the AVR to a 32 bit ARM Cotrex and the mostly non hardware dependent stuff stuff just worked. On the other hand stdint.h is an old friend to me.

Amusing bit

    int apple = 74000; // fails on 8 bit machines

mikestew• 10 years ago

In my case, I'd normally say that Betteridge's law applies. But I did surprisingly well on the quiz.

Though I'd agree with the comments on how this is kind of silly. The answer is not always "I don't know" but rather, in some of those cases, "I didn't define my data types well enough to know for sure, depending on CPU architecture and the compiler".

mark-r3• 10 years ago

I think the point was that if you're writing portable code to the standard, you can't know the CPU architecture and the compiler!

ninjakeyboard• 10 years ago

I don't even know C and I got 100%.

Kenji2• 10 years ago

See? C is so intuitive : )

nano_o• 10 years ago

There is an interesting paper that recently explored the de-facto C standard: Into the Depths of C: Elaborating the De Facto Standards, by Memarian et al. http://www.cl.cam.ac.uk/~km569/into_the_depths_of_C.pdf

rekshaw• 10 years ago

Don't know C. I got all the answers write...do I know C?

yellowapple2• 10 years ago

Yep. You're now a C programmer. Congrats! Linus Torvalds is happily awaiting your first patch to Linux.

jcoffland3• 10 years ago

I know the correct answers to these questions on Linux with an ARM or x86 and on 8-bit AVRs and that's good enough for me.

AceJohnny2• 10 years ago

ARMv6? v7? v8? AArch32? Aarch64? x86? x86_64?

I'm working right now on a system that mixes Aarch32 and Aarch64 cores. Communication between these cores has to be rock-solid.

Previously, I worked on a DSP architecture that could switch at runtime between a 16-bit more and a 24-bit mode. I still sometimes have nightmares. A particular bug that took months to resolve involved app code that expected one mode and interrupts that went into another. The compiler did the right thing most of the time. Most of the time.

pksadiq5• 10 years ago

Do you know the value of 'i' after executing the following statements (assume it's written inside the main function):

int i = 0; int j = sizeof (i++);

// Thanks. :-)

wruza• 10 years ago

Zero with great amount of indeedity.

chetanahuja3• 10 years ago

To all those kvetching about weird C (and by extension, C++) behaviors... what is your alternative for an unmanaged, system level language with broad compiler/library support?

uryga• 10 years ago

Probably nothing :/ However criticisms can be valid without offering alternatives. (if that's what you were getting at)

xenadu02• 10 years ago

We're still fighting to get people to acknowledge that C is a problem. Way too many software engineers are still in denial about that.

D, Rust, and Swift are the only languages I know of that have "systems programming" as a focus.

pjmlp8• 10 years ago

Ada and Spark are a possibility.

You might still try to use FreePascal.

If targeting embedded development, there are a few Basic, Pascal and Oberon compiler vendors to choose from.

And there is also Rust and Swift if you are happy to stay just on Apple OSes (Open source Swift is still a bit of WIP).

dwarman• 10 years ago

Sharing data structures in RAM between 64 bit and 32 bit and 16 bit architectures brings this home painfully. Data communications is equivalently plainful, possibly moreso becaude one has no knowledge of the receiver's architecture. Sending multi-byte values between big- and little-endian machines, for example.

The test could also have included questions on things like packing bools and enums into structures. Again critical to get righht when sharing or transmitting structs, or anything bigger than a char.

3r1kB• 10 years ago

Yep, unfortunately a universal 'Network-Byte_order'[1] stil doesn't exist.

Things like this were especially a pain with industrial network protocols that we used in our applications during the transition from PowerPC to Intel on OS X. All the CFSwapInt16HostToBig() and CFSwapInt16BigToHost() stuff...

And earlier before I learned about '#pragma packed' it took me a while to find out where all these extra zeroes suddenly came from :-D

[1] https://en.wikipedia.org/wiki/Endianness#Networking

golergka• 10 years ago

Correctly answered all the questions.

I'm not C expert, by far; I only have an instinct that if it's about C and memory layout, I shouldn't rely on my understanding and check it instead. On every architecture I'm targeting.

OMGWTF3• 10 years ago

Would question 4 have a different answer if it was:

  unsigned int i = 16;
  return (((((i >= i) << i) >> i) <= i));

? (I changed `int` to `unsigned int`.)

guyzero• 10 years ago

Nope, on 16-bit platforms a 16-bit left shift has a very different result from a 16-bit left shift on a 32 bit platform.

It's basically a question about knowing when you'll get burned by the size of int varying.

OMGWTF3• 10 years ago

So?

  (i >= i)                           // 1
  ((i >= i) << i)                    // 0x10000 or 0
  (((i >= i) << i) >> i)             // 1 or 0
  (((((i >= i) << i) >> i) <= i))    // ((0 or 1) <= 16) == 1

Where did I go wrong?

slavik81• 10 years ago

The C standard requires that the basic int type is at least 16 bits. The same is true of unsigned int. So, either way, 1 << 16 is too large a shift if the integer is 16 bits on your platform.

In section J.2 Undefined Behaviour, the standard mentions that it's undefined when "an expression is shifted by a negative number or by an amount greater than or equal to the width of the promoted expression"

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

joss82• 10 years ago

But wait!

Why would you bit-shift the result of a logical comparison?

This code makes no sense, it's wrong, and should be rewritten.

te_platt• 10 years ago

I'm reminded of an old story about a man trying to fill a job for driving a stage coach. He asks each applicant how close they can drive to the edge of a cliff without going over. The first few applicants brag about being able to right up to the edge. The job goes to the first to respond "I don't know, I try to stay as far away as possible".

tome• 10 years ago

It seems the padding one is wrong for an even simpler reason. You don't know what sizeof(int) is.

davidgerard• 10 years ago

That’s right, Mozart also wrote in C.

applause

sickbeard• 10 years ago

We teach people to write proper code, then they get interviewed on the most dumb half-assed code that nobody writes in the real world because we like mental gymnastics

bogomipz• 10 years ago

I enjoyed this post. I am curious do any of you have any C-specific blogs that you read regularly? Maybe not exclusively C but predominantly C or mostly C-related?

awalton• 10 years ago

If you write a quiz like this, and "Don't Know" is an answer but "Undefined Behavior" and "Implementation-Dependent" are left off, you're doing it wrong.

simosx• 10 years ago

People would figure it out from the start if "Implementation-Dependent" was an option. Perhaps a "Something else" would be more appropriate so that the reader would still be surprised at the end and feel it was a decent multiple-choice test.

sqeaky• 10 years ago

It is likely that the state of someone's knowledge is "don't know" regardless of the actual state of affairs.

If a person wanting to improve guesses correctly, did they actually learn anything? Can they use that next time? They definitely can if they get it wrong and have a wrong answer to start research with.

Edit - I see that I misread your comment, please disregard this. I thought the quiz had don't know and the other options you specified.

acveilleux3• 10 years ago

Or perhaps you're not a native english speaker?

tedunangst2• 10 years ago

Indeed. It's not like the answers are unknowable.

anindha• 10 years ago

I wasn't confused. The first one is pretty obvious it's unknown and "I don't know" is the closest answer.

shp0ngle• 10 years ago

It's pretty clear it's tongue-in-cheek.

cortesoft• 10 years ago

The purpose of this quiz is not to gauge the taker's knowledge of the subject, it is to make a point.

cpkpad• 10 years ago

Indeed. The quiz doesn't start with "What does the ANSI C standard guarantee about..." It says "So you think you know C." C is a cross-platform assembly language. I use it when I need to code to the metal. I know exactly how it will behave in most of those scenarios.

I understand, in abstract, I might be on an EBCDIC system, and things will be different. But that's not the reality of C. C isn't just a formal specification.

I spent a while on 1, thinking about how my compiler would handle that. 2 I was 90% confident about. 3 and 4 I was 100% confident about.

rkangel2• 10 years ago

C isn't just a formal specification

No, C IS just a formal specification.

What you are talking about is C on your particular compiler on your particular platform. If you are writing C code just to be used for that scenario then you can use all of the implementation understanding you want.

If, however, you want to write C that will have consistent behaviour across multiple compilers and multiple platforms, then you need to limit yourself to the behaviours that the standard guarantees. Otherwise the compiler behaviour may change and your program behaviour will change.

Even between different versions of the same compiler implementation defined behaviour can change (although assumptions about sizes probably won't).

jhomedall• 10 years ago

I know exactly how it will behave in most of those scenarios.

Right up until an optimizing compiler throws your assumptions under the bus.

Compilers are allowed to (and both GCC and Clang frequently do) assume that your program will never invoke undefined behavior, and optimize accordingly.

See: http://blog.llvm.org/2011/05/what-every-c-programmer-should-... Also maybe: http://blog.regehr.org/archives/1307

This can lead to some pretty bad security flaws: https://lwn.net/Articles/575563/

kmill• 10 years ago

The question is "what would the return value be," and without knowing which compiler is used you don't know what it would return. It doesn't make sense to say the program returns "undefined behavior" or "implementation-dependent."

You might be taking issue with the question itself, but I think it's a valid question because C compilers tend to be lenient with what they compile.

gkya3• 10 years ago

I can't know != I don't know

Kenji2• 10 years ago

I knew it was Undefined Behaviour, but I played along and tried to guess what it would return on GCC/Windows/x86/no optimisation, in the assumption that the author is clueless about UB and just ran some tests and did a quiz about it.

Sir_Cmpwn• 10 years ago

I realized these were trick questions at #5. My answers till then were "well, on gcc on i686, probably ____". The trick questions are in poor taste imo.

acveilleux3• 10 years ago

I would've thought the first question was a big red flag but I guess in Windows and x86 linux int is 32 bit even with 64-bit processors. Not the case in MIPS64 (under IRIX) or on DEC Alpha.

I had my formative C experience in the DOS era with 16-bit compilers and then SGIs with 64-bit compilers (and I had the "fun" of porting grad student written code from SGI to Linux) so you get burned with expectations about int length. Packing makes it even worse as many RISC machines (like MIPS) are word addressed and non-aligned loads require a bunch of bit fiddling or you get a Bus Error (SIGBUS).

smegel• 10 years ago

Yes, the right answer for every question in “I don’t know”.

Do you think you know the English language?

bnegreve• 10 years ago

Another C quizz, (which I find a little bit more interesting):

Will it optimize: http://ridiculousfish.com/blog/posts/will-it-optimize.html

edit: it's actually about gcc rather than the standard itself, still pretty interesting though.

bjterry• 10 years ago

I sort of understand the point of this post, but I basically disagree with it. From a pedantic perspective, you aren't writing "good C" if your code isn't 100% standards-compliant, but if we applied this same rigor to dynamic languages, no one would get anything done in them. How do you know your Ruby code works? The community has settled on the following solution: because it passes thousands of tests on every aspect of every function. Extending that to C code, your code works if it passes your tests.

Test on every platform and every compiler you support, or it's not going to work. Avoid undefined behavior, sure, that's probably good practice. But there is no need to bend over backwards for compilers from the 90s targeting the AS/400 if you are writing a linux application that only needs to support Ubuntu 16.04. If your only means of avoiding broken behavior is "we're going to try really hard not to do anything undefined or implementation-defined" you will fail. But if you pass your functional tests, your user doesn't care whether you are invoking undefined behavior with every function call.

Cyph0n• 10 years ago

Well said. I'd also add that most of these questions seem aimed at people who've written C compilers before, at least to me. My guess is that even an expert at C like antirez wouldn't really care about such nitpicky issues while writing Redis. Porting Redis to some arcane architecture is a different story entirely however.

nialv7• 10 years ago

Well I would agree that undefined behaviors are unavoidable. Indeed, if you insert checks into your code to completely rule out UB, that will have a huge impact on performance.

On the other hand, I don't agree passing tests is enough. No matter how many tests you run, you can't guarantee there's no bug in your code. This is important especially when security is a critical requirement.

paulftw• 10 years ago

While I get the overall message I'm not sure last question is that unpredictable: I++ + ++I If postfix is executed first it returns 0 but prefix returns 2 and the result is 2. If prefix is executed first it returns 1 and then postfix also returns 1, result of the addition is again 2. What else is ambiguous about this snippet? I can't think of a parse tree that'd evaluate addition before any of the increments - that'd be a syntax error. If the code were (++i + i++) there could be alternative interpretations, but again ++ requires lvalue...

loup-vaillant2• 10 years ago

The order of evaluation in such an expression is entirely unspecified. There are points in C programs that separate a "before" and an "after". The semicolon is a typical such point. There are others. Now between two adjacent points anything goes.

In this particular example the evaluations and effects are allowed to be interleaved:

    pre    = I + 1;      // evaluating the pre-increment
    post   = I;          // evaluating the post-increment
    I++;                 // effect of pre-increment
    I++;                 // effect of post-increment
    return pre + post;   // evaluating the sum

Simply put, pre and post-increment are allowed to occur "simultaneously".

thick18cm• 10 years ago

what you are saying may be correct, but you are "overloading" the term "order of evaluation" to encompass atomicity (atomicity of operations like i++); is that kosher?

pipio21• 10 years ago

The right answer to all this questions is:

"Nobody in their right mind should use code like this in production".

You should avoid code like this at all cost. If you want to use this code because you feel smarter, you will be creating enormous amount of problems in the future and you are actually dumb.

The way to win the game is not playing it. Specially if you are programming nuclear plants.

If you see this code what you have to do is replace it, not understand it. It works today but when you change the compiler or the architecture 10 years from now, it will be such a huge pain in the ass to find all the bugs and undefined behavior it creates.

HelloNurse• 10 years ago

And the key to not playing this undefined behaviour game is using integers of known size. C has them since C99, so using int, short, char etc. like in the article is reckless and inexcusable.

user5994461• 10 years ago

How to recognize a terrible quizz in any programming languages?

Simple. It keeps asking code questions about undefined behaviors that MUST NEVER be used in real world programming.

#StandUpAndLeaveTheInterview

shmerl• 10 years ago

So the author thinks undefined behavior is the esoteric knowledge of C?

blt• 10 years ago

IMO, this is actually a fairly good test of thorough C knowledge. All of these issues are regularly described in articles, blogs, forums, HN posts, etc. Anyone who has programmed C for a few years and put in effort to master the language should know this stuff.

dreta• 10 years ago

THIS is why C is bad. It’s not because there are no classes, and you have to manage your own memory, or because it has unsafe pointers. It’s this. And it’s the same reason why C++ is awful even before you get to the "++" part. I wish that by now we had a proper ASM abstraction language that allows the programmer to work with the architecture they’re programming for, instead of all the “undefined behaviour” we have to deal with since the 70s.

kilon• 10 years ago

You confuse knowing with expertise.

chris_wot• 10 years ago

Even when you know the standard, you will still get undefined behaviour.

So you think you know C?

Related Stories