Tis-interpreter – find subtle bugs in programs written in standard C
github.com
github.com
I'm sick of victim-blaming here. Packages like tis-interpreter are very clever ways to solve problems that shouldn't exist in the first place. The C standard needs to be changed to redefine a bunch of currently undefined behavior as unspecified or completely defined.
> compiler writers take unjustified liberties
How are implementations wrt undefined behaviors unjustified? It's spec'd that way, it's documented that way, there's a good reason why it is that way.
> That the standard permits compilers to interpret memset(0, 0, 0) as __builtin_unreachable() does not justify compilers actually doing so
__builtin_unreachable() is a compile-time hint to the compiler, so for (say) GCC to interpret it that way you'd have to literally write memset(0,0,0) with all constants. Weird example.
Oh by the way, C11 has memset_s, where you can be explicit about what you want. C is good for being explicit. memset() should not try to guess what you mean in an error condition.
> violating programmer expectations.
It's hard to violate expectations that a programmer doesn't have.
While we're talking about “expectations,” let's redefine floating point so that 0.1+0.2==0.3.
> The C standard needs to be changed to redefine a bunch of currently undefined behavior as unspecified or completely defined.
I'd be interested to know how you define, say, signed integer overflow (keep in mind, most DSP architectures don't use two's complement) and invalid pointer dereferences (many embedded CPUs don't have MMUs, please remember them). How about shifting a uint32_t by 32 bits? (x86 and POWER differ on what this does, and I imagine others do too)
C runs on a lot of stuff. Undefined behavior is undefined explicitly _because_ there's not a good solution for every architecture. C gives the programmer the freedom to do what makes the most sense on their architecture and for their use case. Build different higher-level abstractions for desktops and the little signal processor in your phone's modem. There isn't gonna be a solution that works for both. C is for writing fast code in a moderately high-level language. It's not here to make your assumptions for you.
> I'm sick of victim-blaming here.
Alright, I'm sick of this shit on Hacker News. Say something intelligent or don't say anything. Don't use loaded terms like “victim blaming” to cover for your ill-informed opinions on how C should be. If anything, that only downplays real victim-blaming. I don't give a shit what you think C should be. _You're not a victim, you're ignorant_.
Consider this mini example:
void myfunc (int * p) {
int t = *p;
if(p == NULL) { return;}
*p = t + 1;
}
Edit: yes, the replies are right, I meant to dereference *p rather than just copy the pointer. Fixed and somewhat simplified.
I was trying (badly) to remember this example: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Edit: I'm a moron, thanks for pointing out the obvious to me :)
Of course if you pass a pointer to a type smaller than sizeof(int)-1 bytes then it accesses uninitialized memory which is UB, but that's a different issue.
EDIT: Aaaand I wasn't thinking.
̶E̶D̶I̶T̶ ̶E̶D̶I̶T̶:̶ ̶N̶o̶t̶ ̶o̶n̶l̶y̶ ̶d̶i̶d̶ ̶I̶ ̶m̶i̶s̶-̶r̶e̶a̶d̶,̶ ̶b̶u̶t̶ ̶v̶o̶i̶d̶ ̶p̶o̶i̶n̶t̶e̶r̶ ̶c̶a̶n̶'̶t̶ ̶a̶l̶i̶a̶s̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶ ̶i̶n̶ ̶s̶t̶a̶n̶d̶a̶r̶d̶ ̶C̶ ̶a̶n̶y̶w̶a̶y̶ ̶(̶t̶h̶o̶u̶g̶h̶ ̶I̶I̶R̶C̶ ̶G̶C̶C̶ ̶t̶r̶e̶a̶t̶s̶ ̶i̶t̶ ̶l̶i̶k̶e̶ ̶c̶h̶a̶r̶ ̶p̶o̶i̶n̶t̶e̶r̶ ̶w̶r̶t̶ ̶a̶l̶i̶a̶s̶i̶n̶g̶)̶.
EDIT EDIT EDIT: Actually maybe it can and I shouldn't be reading technical docs at 2am.
You should read about strict aliasing, you will be surprised.
Somehow I wasn't thinking and didn't realize that `t` aliases whatever was passed as `p`, and dereferencing a non int or char pointer would be undefined there.
This is true as dereferencing a NULL pointer is undefined behaviour, so is fair game for optimizations. The compiler may assume that NULL pointer dereferencing results in a trap/segfault and that the conditional can never be executed.
If I am wrong, and your example actually exhibits undefined behaviour, I would certainly love to learn why.
Your example is plain wrong.
struct foo {
int bar;
}
void myfunc(struct foo *p) {
int *t = &p->bar;
if(p == NULL) return;
*t = 5;
}
...
void myfunc(struct foo *p) {
int *t = (int *)((char *)p + offsetof(p->bar));
...
}
Annex K, so unfortunately that isn't widely available and unlikely to ever be. Also, there is a performance hit for where it is available [0].
[0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
Programmers still need to track pointer and length parameters separately, leading to the usual set of memory corruption.
Many of these things are spec'd and documented that way because there happened to be some really obscure systems that fell out of use decades ago where the sensible, obvious behaviour wasn't possible - not because the standard-writers expected compiler developers to get a speed boost out of it. C didn't even have the restrict keyword until relatively late in its life, and I'm not sure C++ does even now; enabling aggressive compiler optimizations was not high in the priority list.
> I'd be interested to know how you define, say, signed integer overflow (keep in mind, most DSP architectures don't use two's complement)
Most DSP architectures can't run C code written for general-purpose computers because they don't support byte addressing. As far as I know most or all of them are two's complement though. The main other difference is that they support saturating arithmetic because some code needs it, though since you can't access that from C because signed integer overflow is undefined...
The newest one's complement or sign-magnitude systems anyone seems to be able to find are ancient Sperry-Burroughs mainframes.
What's your opinion of What every compiler writer should know about programmers? http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201...
I could take that document more seriously if it didn't make compiler writers out to be evil.
There's a good reason that I and many other people continue to complain about compilers' adventurous interpretation of the standards. You persist in blaming programmers who clearly indicate the intent of their programs for compiler writers ignoring that intent in search of faster benchmarks, using bits undefined behavior intended to account for platform differences to actually distort programs.
> It's spec'd that way
Yes. So what? The spec is harmful. It is a bad spec. It doesn't reflect C as actually written.
> it's documented that way
Yes. So what? Not every documented behavior is good.
> there's a good reason why it is that way
Absolutely not. memset, memcpy, look and act like normal functions and only have this weird undefined behavior by special dint of the relevant standards. That's very surprising and leads to real bugs.
Other undefined behavior is similar. There's no reason on modern systems to make arbitrary pointer arithmetic undefined. There is no reason to make signed integer overflow undefined either --- unspecified, maybe, but certainly not undefined.
(Except, that is, for loop optimization, but that's a bullshit and lame excuse that compiler writers use to avoid having to do real bounds inference.)
> memset() should not try to guess what you mean in an error condition.
That's not a fucking error condition, and you know it. memset(0,0,0) to any honest person means "do nothing to zero bytes", not "make my program do whatever compiler authors want". memset and memcpy of NULLs can occur in normal program logic, sometimes surprisingly, and there is absolutely no legitimate reason for treating these occurrences as undefined behavior.
> let's redefine floating point so that 0.1+0.2==0.3.
You know damn well that there's a good reason IEEE754 floating point is inexact when expressed in decimal. That's not the case with the undefined behavior that compiler writers currently exploit.
> How about shifting a uint32_t by 32 bits?
Specify that it returns zero or the original value, but don't allow the compiler to consider it unreachable, trap, or do other random shit.
> Alright, I'm sick of this shit on Hacker News.
The tone of your post and others like it is intolerable. It is precisely victim blaming. Compiler writers aren't taking advantage of undefined behavior to account for DSPs: they're doing it to win benchmarks that don't matter in the real world. (The memset issue is particularly egregious.) This process harms users and developers by introducing bugs.
You're the one who's badly-informed, not me. Practically every program, even extremely well-tested ones like SQLite, contain undefined behavior. See http://blog.regehr.org/archives/1292. (Read the whole blog, actually.)
Now, what good does it do say that almost every C program on earth is actually at fault? That's just giving compiler writers license to do whatever they'd like. When even very careful programmers trip over obscure parts of the standard, it's the standard that must change.
> using bits undefined behavior intended to account for platform differences to actually distort programs.
You can't really distort a program that doesn't have a valid interpretation to begin with.
> Yes. So what? The spec is harmful. It is a bad spec. It doesn't reflect C as actually written.
The spec is written to be cross-platform, and C as it is actually written typically is not cross-platform. Which is fine, actually, since generally programs don't need to run on both bare metal on a microcontroller and on a supercomputer. Portable between similar-purpose processors is enough.
The spec probably shouldn't reflect C as it is written anyway, rather C should be written to reflect the spec....
> memset, memcpy, look and act like normal functions and only have this weird undefined behavior by special dint of the relevant standards.
Can't any function do anything if that's part of its contract? We can write a div(x,y) function that deletes System32 if you divide by 0, and just say that division by zero is undefined.
> There's no reason on modern systems to make arbitrary pointer arithmetic undefined.
Fair enough.
> There is no reason to make signed integer overflow undefined either
That one is actually rather important for performance though.
> (Except, that is, for loop optimization, but that's a bullshit and lame excuse that compiler writers use to avoid having to do real bounds inference.)
https://gcc.gnu.org/contribute.html
> memset(0,0,0) to any honest person means "do nothing to zero bytes"
Yes, we really need more honest people to write compilers.
I think appealing to “honest person” or “what most people would expect” etc is a weak argument. Sometimes the correct behavior isn't what people expect, and sometimes there is no correct behavior.
> memset and memcpy of NULLs can occur in normal program logic, sometimes surprisingly
I believe that'd be an error condition. Check for NULL before you memcpy to NULL. Frankly though the circumstances where you memcpy or memset something that even could be NULL is pretty rare. Usually it's something recently allocated (stack or heap).
> Specify that it returns zero or the original value, but don't allow the compiler to consider it unreachable, trap, or do other random shit.
That would be reasonable. Perhaps some things, such as shifting, could be implementation-defined. I did, I think, ignore the idea that some undefined things could just be unspecified in my original rant.
> That's not the case with the undefined behavior that compiler writers currently exploit.
Perhaps not in all cases, but in many cases there is a good reason for undefined behavior being undefined: it doesn't make sense in the context of the C abstract machine. Derefencing a NULL pointer, for example, may be perfectly valid on an embedded CPU with no memory protection. C isn't defined to “how this should work on my x86_64 Macbook Pro,” it's defined to “how this should work—or not work—on the C abstract machine.” If on some particular implementation of the C machine that means “delete this basic block at compile time” then so be it. You're not entitled to tell compiler writers how to interpret undefined behavior.
> The tone of your post and others like it is intolerable. It is precisely victim blaming.
Yes, the evil evil compiler writers are conspiring to look good in benchmarks and poor programmers are the victims. Victims!
You are so damn ungrateful it hurts. You're not a fucking victim.
> Practically every program, even extremely well-tested ones like SQLite, contain undefined behavior.
I keep pondering whether this is a problem or not. If the compiler can't prove that it's undefined at compile time, then it just depends on the processor and the only problem is that your program is not portable to obscure special-purpose architectures. On the other hand, the fact that any non-trivial program needs to invoke undefined behavior is pretty damning evidence that the spec is insufficient.
I think, ultimately, I concede that the C standard is flawed. But please get over your fucking entitlement complex about how compiler writers take more liberties with UB than you would.
Basically every DSP uses two's complement, and pretty much everything else besides, and has for decades. Most things that give different results based on the representation of negative numbers are merely implementation-defined, anyway. Signed overflow is undefined for a different reason.
for (i = 0; i < n; i++) {
foo();
}
In general I agree with your point, though. If those kinds of optimizations don't matter to you, you shouldn't be using C. If you want the option for your loops to run (4,294,967,296 + n) times in C, use unsigned arithmetic. Its overflow behavior is well-defined.