July 14, 2015 Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749 Safety is one of the more important things that D offers over C++, even though people keep saying C++11/14 makes D unimportant. |
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | On Tuesday, 14 July 2015 at 03:35:08 UTC, Jack Stouffer wrote:
> http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749
>
> Safety is one of the more important things that D offers over C++, even though people keep saying C++11/14 makes D unimportant.
Uhm, no. The linked page concludes that security-oriented software should be written in languages that trap on integer overflow by default.
D is not better off by having modulo-arithmetics, that means you cannot even catch overflow related issues by semantic analysis, since overflow does not exist. There are C-like languages that ensures that overflow is not possible at compile time (by putting limits on loop iterations and doing heavy duty proofs).
|
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Tuesday, 14 July 2015 at 07:43:27 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 July 2015 at 03:35:08 UTC, Jack Stouffer wrote:
>> http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749
>>
>> Safety is one of the more important things that D offers over C++, even though people keep saying C++11/14 makes D unimportant.
>
> Uhm, no. The linked page concludes that security-oriented software should be written in languages that trap on integer overflow by default.
>
> D is not better off by having modulo-arithmetics, that means you cannot even catch overflow related issues by semantic analysis, since overflow does not exist. There are C-like languages that ensures that overflow is not possible at compile time (by putting limits on loop iterations and doing heavy duty proofs).
The article concludes: "There are many more modern and much safer languages that either eliminate the UB entirely through language design (e.g. using a garbage collector to eliminate an entire class of memory safety issues, completely disallowing pointer casts to enable TBAA safely, etc), or by intentionally spending a bit of performance to provide a safe and correct programming model (e.g. by guaranteeing that integers will trap if they overflow). My hope is that the industry will eventually move to better systems programming languages, but that will take a very very long time..."
__e.g. using a garbage collector to eliminate an entire class of memory safety issues__
Now one may say that this isn't all he was saying, that the GC in D can be improved, that D could be safer, and so on. But it's hardly fair to suggest the original poster is not right about one of the advantages of D vs C and C++. Or at least you ought to make that argument rather than just pick on one fragment of the linked piece, without considering the overall point.
|
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Tuesday, 14 July 2015 at 07:43:27 UTC, Ola Fosheim Grøstad wrote:
> Uhm, no. The linked page concludes that security-oriented software should be written in languages that trap on integer overflow by default.
>
> D is not better off by having modulo-arithmetics, that means you cannot even catch overflow related issues by semantic analysis, since overflow does not exist. There are C-like languages that ensures that overflow is not possible at compile time (by putting limits on loop iterations and doing heavy duty proofs).
Correct software can't be written in C because of UB, that's why safer languages are praised for elimination of UB.
|
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laeeth Isharc | On Tuesday, 14 July 2015 at 08:54:42 UTC, Laeeth Isharc wrote: > Now one may say that this isn't all he was saying, that the GC in D can be improved, that D could be safer, and so on. But it's hardly fair to suggest the original poster is not right about one of the advantages of D vs C and C++. The linked webpage explicitly states that C UB for integer overflow gives 2x performance in some scenarios. Something these forums have tried to play down many times. You have compiler-options/libraries/tools for C++ that allows you to write as safe and safer code than D (which lacks sanitizers) at the cost of performance and convenience. Just like D defaults sacrifice performance for the same, but D tries to give priority to convenience. Which C++ does not have much of (convenience that is). C++ has an impressive range of options that beats all alternatives in the flexibility-department, but also high complexity levels and tedious syntax. It is just that if you use C++ over Java you do it because you need performance and deliberately through-and-through avoid those features/library/compiler options/tools and resort writing code that is less robust. My C++ libraries do void casts and lots of other low level stuff, not because C++-eco system does not provide robust alternatives, but in order to work with raw memory. I would never dream of doing that in a language like Go or Java. I do it because I _need_ the performance that C/C++ brings and also need to tailor low level constructs/hardware/OS. Which I could not do at all in Go/Java. If you do the same in D, you are in the same boat as C++, except C++ is more tedious and C++ provide sanitizers. But there are restricted and annotated versions of C that offers provable safety at the cost of development time, but with C performance. Thus is much better than D for _secure_ performant system level programming since you also have both termination and run-time guarantees. Of course, nobody use D for critical system level programming, so that is not really an issue in the forseeable future. Good enough rebuttal? Slamdunk C/C++ for the right reasons: complexity and tedium. Complexity and tedium make people more likely to make fatal mistakes... but that's ergonomics, not semantics. |
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Tuesday, 14 July 2015 at 09:29:03 UTC, Kagamin wrote:
> On Tuesday, 14 July 2015 at 07:43:27 UTC, Ola Fosheim Grøstad wrote:
>> Uhm, no. The linked page concludes that security-oriented software should be written in languages that trap on integer overflow by default.
>>
>> D is not better off by having modulo-arithmetics, that means you cannot even catch overflow related issues by semantic analysis, since overflow does not exist. There are C-like languages that ensures that overflow is not possible at compile time (by putting limits on loop iterations and doing heavy duty proofs).
>
> Correct software can't be written in C because of UB, that's why safer languages are praised for elimination of UB.
This is 100% wrong. UB only happens in the code gen for programs that are illegal (per definition incorrect source code).
If your program is correct, then the code cannot trigger UB.
|
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | Please also note that C is a low level language geared towards supporting all kinds of reasonable ALUs. A language like D or Rust cannot efficiently compile to a CPU that is hardwired to trap on overflow. C can. A language that requires detection of overflow cannot efficiently compile to an ALU that cannot detect overflow directly (like some SIMD instructions). C can. In C undefined behaviour just means that overflow is defined as an illegal situation and is underspecified in order to allow efficient code gen for a wide variety of hardware (like trapping or spilling over into a different "simd" register). It does not mean that the compiler MUST do something weird, it means that the compiler isn't absolutely required to provide sensible output for incorrect programs. You are free to use a C/C++ compiler that provides a switch where overflow leads either to an abitrary value (Rust semantics) or the wrap around (D code gen). At the cost of performance or portability. Making unpleasant choices for "undefined behaviour" is not a language feature. It is a compiler vendor customer-relation strategy or a RTFM issue... |
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | Omitted from your comments are any mention of D's language support for purity and transitive const/immutability and @safe/@trusted/@system. These are critical for writing robust, encapsulated code. I know of no C++ sanitizers that attempt to address these. Also, the Warp project shows that D can be every bit as performant as C++, while being a lot easier to get there. And lastly, writing code in C++ does not get you performance. Performance comes from careful balancing of algorithms, data structures, memory layout, cache issues, threading, and having intimate knowledge of how your particular compiler generates code, and then using a profiler. D provides access to tuning every one of these issues. Anyone familiar with those issues at the level needed to write performant C++ will also find it straightforward to avoid performance issues with D and the GC. Have you used a profiler for your performance critical C++ code? You don't have to answer, but very, very few C++ programmers do. And I can guarantee you that those that don't use a profiler are not writing performant code (though they certainly may believe they are). |
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 14 July 2015 at 10:32:35 UTC, Walter Bright wrote: > Omitted from your comments are any mention of D's language support for purity and transitive const/immutability and @safe/@trusted/@system. These are critical for writing robust, encapsulated code. I know of no C++ sanitizers that attempt to address these. Yes, if your codebase benefits from transitive const/immutability then that can simplify reasoning about the program. I usually don't write code that way in C-like programming and prefer more fine-grained const to prevent myself from making encapsulation-related mistakes more than multi-threading issues etc. In the ideal world I would want both. In the real world complexity is already higher by having const in the first place... so I understand the trade-off. > And lastly, writing code in C++ does not get you performance. Performance comes from careful balancing of algorithms, data structures, memory layout, cache issues, threading, and having intimate knowledge of how your particular compiler generates code, and then using a profiler. Indeed. But you would not have written DMD in C++ if you did not need performance? That was more my point. C++ is not an attractive language if you can afford slower execution. Languages like D and Go can stay interesting alternatives even when you can accept slower execution, but want strict typing and GC. So for people who only want one language D has an advantage over C++, right there. (I don't really care, since I already deal with many languages every month.) > Have you used a profiler for your performance critical C++ code? You don't have to answer, but very, very few C++ programmers do. And I can guarantee you that those that don't use a profiler are not writing performant code (though they certainly may believe they are). I basically don't care about raw throughput, but latency and meeting real time deadlines. Instrumentation can be useful… but I consider that "debugging". My C/C++ bottlenecks are in tight loops with real time constraints on a single thread. Meaning, if it is too slow I will get dropped audio/video frames. So I write the code as fast as I conveniently can, taking heights for the possibility that I might have to go even lower level... (and hoping I don't have to). So I don't write optimal code from the get go. I try to write maintainable code first using "CPU independent simd" and decent cache-friendly layout. Of course, a compiler is different since there are no latency issues, but throughput issues. Then you need to look at the whole call-tree using perf-counters etc. But I think many situations where you need C/C++/D/Rust/Go are situations dominated by responsiveness/latency. |
July 14, 2015 Re: Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Tuesday, 14 July 2015 at 09:44:08 UTC, Ola Fosheim Grøstad wrote: > On Tuesday, 14 July 2015 at 08:54:42 UTC, Laeeth Isharc wrote: >> Now one may say that this isn't all he was saying, that the GC in D can be improved, that D could be safer, and so on. But it's hardly fair to suggest the original poster is not right about one of the advantages of D vs C and C++. > > The linked webpage explicitly states that C UB for integer overflow gives 2x performance in some scenarios. Something these forums have tried to play down many times. Perhaps - I haven't measured these things myself, and don't recall downplaying of this in the short term I have been here, but I have no reason to think that's wrong. But my point was one of good form. You seemed to slam the original poster, who who made no stronger or more concrete assertion than that safety is a benefit of D [we surely know by now that linking to a piece implies endorsement of it only as being interesting, not more]. Perhaps that's a point well-founded in reality, but I didn't see you argue for it. I have no interest in pursuing controversy further, but it really is a mystery to me as to why you don't do something constructive towards shaping the world as you would like to see it. Code wins debates, and a DIP is less work than implementing the whole thing oneself. It is of course possible there is background to which I am not privy, and that that is why it is mysterious. > You have compiler-options/libraries/tools for C++ that allows you to write as safe and safer code than D (which lacks sanitizers) at the cost of performance and convenience. Just like D defaults sacrifice performance for the same, but D tries to give priority to convenience. Which C++ does not have much of (convenience that is). C++ has an impressive range of options that beats all alternatives in the flexibility-department, but also high complexity levels and tedious syntax. I'll certainly take programmer productivity if I don't need to pay too much for it, and if the aesthetic experience of getting my stuff done can be made something pleasurable. I am not sure however if you are making an argument to justify your implicit position, since it seems we both have similar assessments of C++ as its used, or easy to use. I do not think it is controversial either to observe that C++ has more options! Life in the commercial world involves pragmatic choices. So the missing piece in your argument would be to demonstrate that programmer productivity ('convenience') and non-tedious syntax are not all that important. Conventional wisdom seems to be that productivity matters more than efficiency (personally I don't mind trading off a little, but there are limits!) > It is just that if you use C++ over Java you do it because you need performance and deliberately through-and-through avoid those features/library/compiler options/tools and resort writing code that is less robust. I don't know - I think there are many factors that go into such a decision. It's a big world, and I wouldn't pretend to know what shapes problems in different domains. What is discussed in the media is not necessarily representative of what actually goes on amongst people quietly getting their work done. I am told that Java is often faster than C++ and needn't be a memory hog - maybe that is right, but in practice stuff written in C,C++,D in a sensible, mature, thoughtful fashion but without too much special effort given to optimisation seems to just run fast without a need for tuning or any dark magic. I am probably not tuning it right, but even in 2015 one doesn't seem to be impressed by the performance and memory efficiency of Java apps. > My C++ libraries do void casts and lots of other low level stuff, not because C++-eco system does not provide robust alternatives, but in order to work with raw memory. I would never dream of doing that in a language like Go or Java. I do it because I _need_ the performance that C/C++ brings and also need to tailor low level constructs/hardware/OS. Which I could not do at all in Go/Java. > > If you do the same in D, you are in the same boat as C++, except C++ is more tedious and C++ provide sanitizers. Do you need to in the whole part of what you are writing, and if you do, are you in the same boat? > But there are restricted and annotated versions of C that offers provable safety at the cost of development time, but with C performance. Thus is much better than D for _secure_ performant system level programming since you also have both termination and run-time guarantees. But commercial life is about trade-offs and pragmatic choices, and the Pareto principle applies here too. Ie I should think the subset of reasonably secure, reasonably efficient systems level programming is rather larger than the narrow domain you speak of above. > Of course, nobody use D for critical system level programming, so that is not really an issue in the forseeable future. I don't know what "systems programming" means any more, only what it meant 30 years ago. Wouldn't you say that Weka, Sociomantic, possibly the guys doing the Norwegian subway announcement system have at least aspects of system level programming and can be described as critical? The hedge fund about which Andy Smith spoke - their application may or may not be systems level, but it strikes me as not so far from that. > Good enough rebuttal? Slamdunk C/C++ for the right reasons: complexity and tedium. Complexity and tedium make people more likely to make fatal mistakes... but that's ergonomics, not semantics. A rebuttal would have been to demonstrate that the OP was making a silly point that cannot be justified. You have yourself suggested that if you want to use C and C++ in a safe way then it comes at quite a price. Commercial adoption is after all driven by these sorts of things. |
Copyright © 1999-2021 by the D Language Foundation