C Questions and Answers • Hacker News Board

Re: C Questions and Answers

#21

Post by Veedrac » Wed, Mar 04, 2015, 7:13 AM UTC

A trickier variant of #11 is to show people

    bool is_zero(int x) {
        return x == -x;
    }

    bool is_zero(float x) {
        return x == -x;
    }

and ask them which is wrong and for what value. Most of the time the instinctive response is that it must be the float code (because floats are evil, duh).

This works even in languages with defined overflow for integers.

Re: C Questions and Answers

#22

Post by rav » Wed, Mar 04, 2015, 7:15 AM UTC

EpicEng wrote: post #9

Well apparently I do know C. If the author wanted to be as contrived a possible there are certainly more devious edge cases which could have been trotted out. The fact that e.g. the compiler may optimize out a NULL check after you've already dereferenced the darn thing shouldn't be surprising. Just fix your silly bug.

The problem is that (correct me if I'm wrong) an expression like "&foo->bar" counts as a dereference of foo, even though the result of the expression is simple pointer arithmetic involving foo (adding the offset of the bar member).

Re: C Questions and Answers

#23

Post by rav » Wed, Mar 04, 2015, 7:17 AM UTC

Veedrac wrote: post #21

A trickier variant of #11 is to show people bool is_zero(int x) { return x == -x; } bool is_zero(float x) { return x == -x; } and ask them which is wrong and for what value. Most of the time the instinctive response is that it must be the float code (because floats are evil, duh). This works even in languages with defined overflow for integers.

But you should give the functions different names, since it is not valid to define the same symbol more than once (and there's no name mangling in C that enables function overloading).

Re: C Questions and Answers

#24

Post by pcwalton » Wed, Mar 04, 2015, 7:21 AM UTC

rav wrote: post #22

EpicEng wrote: post #9

Well apparently I do know C. If the author wanted to be as contrived a possible there are certainly more devious edge cases which could have been trotted out. The fact that e.g. the compiler may optimize out a NULL check after you've already dereferenced the darn thing shouldn't be surprising. Just fix your silly bug.

The problem is that (correct me if I'm wrong) an expression like "&foo->bar" counts as a dereference of foo, even though the result of the expression is simple pointer arithmetic involving foo (adding the offset of the bar member).

Yes, you're correct [1], and that's why offsetof is a builtin in gcc and clang.

Even more insidious is the fact that memcpy of zero bytes from or to null is undefined behavior.

[1]: http://stackoverflow.com/questions/26906621/does-struct-name...

Re: C Questions and Answers

#25

Post by azinman2 » Wed, Mar 04, 2015, 7:21 AM UTC

fdik wrote: post #17

Already the first example is wrong. So I stopped reading. % cc -std=c11 -o dingens dingens.c dingens.c:6:9: error: redefinition of 'i' int i = 10; ^ dingens.c:5:9: note: previous definition is here int i; ^ 1 error generated. % cat dingens.c #include int main() { int i; int i = 10; printf("hello, world\n"); return 0; } %

That's because you put it inside a function versus inside the file outside of a function. It'll compile then, even on clang with -std=c11. I just tried it now and it worked.

From his webpage: "Reminding you that it’s a separate source file and not a part of the function body or compound statement"

Re: C Questions and Answers

#26

Post by rtpg » Wed, Mar 04, 2015, 7:23 AM UTC

_RPM wrote: post #2

This reminds me of tests I took in earlier CS classes. Knowing those things are utterly useless in practice.

only useless if you never make a mistake ever. This shows what you should be vigilant for (alternatively , an argument for using a language with more checks)

As someone on HN once said (in jest), it's easy to write bug-free C, you just need to never make a mistake ever and spend a million hours auditing it.

Re: C Questions and Answers

#27

Post by obstinate » Wed, Mar 04, 2015, 7:25 AM UTC

fizixer wrote: post #5

He's discussing subtle points of the C language and yet there is no mention of which compiler he's using, whether the results might be different for different compilers, hardware platforms, and how they correlate with multiple C standards (C89, C99, C11/C1X, etc). He succeeded in convincing me that he does not know C!

Since he's talking about undefined behavior in a lot of the cases, the answer to all your questions is, "Yes." That's pretty obvious, so maybe he thought it went without saying.

Re: C Questions and Answers

#28

Post by sjolsen » Wed, Mar 04, 2015, 7:30 AM UTC

fizixer wrote: post #18

sjolsen wrote: post #6

Earlier quoted context omitted.

There is no mention of which compiler he's using or whether the results might be different for different compilers and/or hardware platforms precisely because he's discussing the C language— not the idiosyncrasies of particular implementations. >and how they correlate with multiple C standards There's nothing going on here specific to any particular revision of ISO C (that I can see).

Too much of a coincidence! Did he make sure the behavior he mentioned is uniform across all ISO standards? What is his source for coming up with a certain answer to a certain piece of code? any of the standard documents? K&R book? gcc output? As an example: In the answer to point 2, he claims: > ... the compiler thinks that x cannot be a null pointer ... First of all, this gives a strong indication that he's analyzin…

>Did he make sure the behavior he mentioned is uniform across all ISO standards?

I don't know.

>What is his source for coming up with a certain answer to a certain piece of code?

His conclusions are consistent with my understanding of the C standard. His justifications for his conclusions refer to specific rules regarding program behaviour, which suggests he's using the standard(s).

>First of all, this gives a strong indication that he's analyzing a compiler output, a compiler that he didn't reveal in the article.

He is using the output of some compiler to illustrate the potential consequences of making the given mistake. It doesn't really matter which; the point is that it is not legal to perform lvalue-to-rvalue conversion on the result of indirecting through a null pointer.

>could you or him point me to any page in the C99 standard document where it is explicitly stated along the lines that the compiler "should assume" the pointer to be not NULL after an undefined dereferencing in line (1) and hence ignore (2) and (3)?

No, because the C99 standard document does not say that. What it does say is effectively that the compiler MAY assume the pointer not to be null; more generally, the compiler is allowed to assume that the program never exhibits undefined behaviour.

Re: C Questions and Answers

#29

Post by dllthomas » Wed, Mar 04, 2015, 7:31 AM UTC

I'll readily admit that there are corners of C where I would not be able to tell you just what breaks. But I know about where they are and enough to stay away from them. If I'm not sure, the next guy won't be either.

I got 12/12 here. I would say I know C.

Re: C Questions and Answers

#30

Post by ChuckMcM » Wed, Mar 04, 2015, 7:32 AM UTC

I think this was silly, the author clearly does know C but they are complaining about optimizing compilers which do things "behind your back" and are becoming an increasing nuisance. It's sort of a passive aggressive "I think this should be an error but it isn't an error because twisted logic that the compiler uses with respect to undefined operation."

That people can teach themselves what to expect the compiler to do isn't all that surprising, and it also isn't surprising that a "modern" compiler does stuff an "old" C programmer might think is ridiculous.

I've engaged in this particular argument a few times only to throw up my hands in frustration over some exquisitely twisted line of reasoning that gave the compiler hacker person a fraction of a percent improvement[1] by exploiting this kind of situation. As long as I have a compiler flag that turns it all off its tolerable. But sheesh, sometimes I think these are C programmers who don't have the guts to become Rust programmers. You want to start fresh dudes, clean slate. Embrace it.

[1] "But Chuck, over the millions of machines out there its like an entire computer's worth of CPU cycles you can use for something else!"