3 ms·
> I would assert that virtually every non-trivial C/C++ program First, citation needed. Second, the programs I work on would fall outside of your "virtually e
by jjnoakes 11y ago
> I would assert that virtually every non-trivial C/C++ program
First, citation needed.
Second, the programs I work on would fall outside of your "virtually every".
> [big list of things]
This list doesn't prove anything. There's a similar list in the standards themselves. That's how we know what to avoid.
Oh, and we have an in-house static analysis program that catches all of those. And more.
Our code simply has no undefined behavior. It passes our static analysis program, it passes UBSAN, and no compiler has ever miscompiled our code (unless it was due to a compiler bug).
You can try all you like, but there's no way for you to convince me that our code has undefined behavior. And there are plenty of projects out there similar to ours.
> if you have any sort of custom memory allocation scheme, you're pretty much guaranteed to break this
Not true. You should learn about the aliasing rules before you speak authoritatively about them.
> Functions like memcpy or malloc cannot legally be written in C without breaking this behavior
Also not true.
> Your program probably has undefined behavior.
The chances of that are much less than the chances of you not knowing what you are talking about.
- dzdt 11y agoSibling post gave a case study as a citation providing evidence of the assertion: http://blog.regehr.org/archives/1292 http://blog.regehr.org/archives/1292 In that case (sqlite) code that passed UBSan, ASan, valgrind, and compiled correctly on all current compilers was studied. A new dynamic undefined behavior checker found additional UB defects at a rate over 1 per thousand lines of code. I would believe your codebase could have a defect rate one, maybe even two orders of magnitude lower. But short of a formal code-correctness proof, better than that seems unlikely.
- jcranmer 11y agoIt is nothing short of sheer hubris to believe that you have avoided all undefined behavior, particularly given that there exist undefined behaviors that have no extant static or dynamic checkers (hi, strict aliasing). I do know the strict aliasing rules quite well. As I said in a cousin post, the set of permissible accesses to a lvalue are governed by the dynamic type of an object. As a consequence, strict aliasing queries are not symmetric, which is to say, P* could point to an object of type Q* but not vice versa. The case where this will come up is with signed/unsigned char. If you have a char foo[]; as the dynamic object, it is positively illegal to access that with anything other than unsigned or signed char. This is what really screws up a lot of code.
- jjnoakes 11y agoStrict aliasing violations are quite simple for a static analysis program to find and report. > I do know the strict aliasing rules quite well. Not well enough, if you think what you wrote above ("memcpy or malloc cannot legally be written in C without breaking this behavior") is true.
- astrange 11y ago> Functions like memcpy or malloc cannot legally be written in C without breaking this behavior > Also not true. You cannot implement malloc in C because malloc always returns a pointer that's not a part of an existing allocation. The malloc in libc has special dispensation from the compiler to do this (GCC "malloc" attribute). Similarly you can't implement pthread mutexes in C because they imply optimization barriers (all global memory might change) that a C function with a visible implementation wouldn't have.
- dsfuoi 11y agoYou can easily implement malloc. I don't understand what relevance with this your paragraph has. C11 has atomics and all the necessary primitives, fences, locking, etc..., to implement pthread_mutex, including its own mutex.