101–110 of 111 posts
I'd like to be able to type something like:
gcc -march=x86-64-safe my_buggy_server.c
Earlier quoted context omitted.
> The speed of development was very low, Not a part of GP's assertion > and how many people can check the proofs? it's not necessary, the proofs are checked using automation. I'm directly taking a shot at this assertion: > Static analysis tooling has demonstrated that it isn’t up to the task
Just because you have a proof doesn't mean it proves the right thing.
Earlier quoted context omitted.
Where did I mentioned the kernel? And no, that is not correct. Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++. Windows (32 bit variants) and OS/2 userspace has always been a mix of C and C++. BeOS userspace was C++. Symbian was full C++, including the kernel by the way.
> Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++. That doesn't ring true at all. Object Pascal was a rather short-lived project at Apple. It was only seriously used for the MacApp framework -- which was a separate product sold to application developers, not part of the core OS or development tools -- and was abandoned entirely during the PowerPC transition. Later versions of MacApp…
% find ~/Downloads/System\ 7.1\ Source/ -type f -print0 | xargs -0 -n 1 basename | cut -d. -f 2- | tr '[a-z]' '[A-Z]' | sort | uniq -c | sort -rn | head -20
869 A
308 H
189 C
162 P
85 R
69 MAKE
31 M.A
28 O
11 RSRC
11 AII
...Earlier quoted context omitted.
A large number of those came only usefully into existence in 1998, with C++98 string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr in C++98 I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.
> And with STL, it still took another 5 years for the compilers to be good enough. This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many…
If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.
> In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. Would be interested to know examples for this.
The whole paragraph: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. ... goes against MISRA C, which certainly is preferable in the domain I work, embedded systems - because dynamic allocations all…
Earlier quoted context omitted.
The whole paragraph: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. ... goes against MISRA C, which certainly is preferable in the domain I work, embedded systems - because dynamic allocations all…
GNU is about making software for the end-user, that's the opposite of what MISRA is about
A significant number of these CVEs are related to dynamic memory allocation (double-free, use-after-free).
Probably not all are the result of that piece of advice and probably some of those memory allocations were necessary, but since this class of errors is common in C/C++, I believe it is really not a good idea to encourage people to point the gun right to their feet.
On a side note, please explain to me how this is end-user oriented in a system where the convention is that a program ends silently when everything went smoothly:
> In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message [...] Explain the problem with comments in the source.
Earlier quoted context omitted.
GNU is about making software for the end-user, that's the opposite of what MISRA is about
https://www.cvedetails.com/vulnerability-list/vendor_id-72/G... A significant number of these CVEs are related to dynamic memory allocation (double-free, use-after-free). Probably not all are the result of that piece of advice and probably some of those memory allocations were necessary, but since this class of errors is common in C/C++, I believe it is really not a good idea to encourage people to point the gun righ…
Earlier quoted context omitted.
A large number of those came only usefully into existence in 1998, with C++98 string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr in C++98 I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.
> And with STL, it still took another 5 years for the compilers to be good enough. This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many…
Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.
Shipping libraries that leak STL types all over the place will only give you headache.
> In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message. These checks indicate the existence of bugs. Whoever wants to fix the bugs will have to read the source code and run a debugger. So explain the problem with comments in the source. But then the person RUNNING the program will only see this: Abort trap: 6 And that's all the info you'll get from their b…
It's hard to imagine that directive lasting beyond the first bug report of "it broke, fix now!".
There is another aspect, C and C++ are not memory safe languages so the bug may not be particular logical (i.e. some kind of memory corruption). In these cases I actually prefer something to the like of __builtin_trap instead of abort. Calling any code after an invalid invariant has been detected clobbers registers and may make it impossible to investigate the state at the time of the "crash". Some features of modern optimizing compilers make this even worse, such as abort being marked as "noreturn".
Earlier quoted context omitted.
What about SEL4?
I've got a strong background in formal verification. I do not believe that "formally verified" means "security bug free". In fact, I personally know researchers who have had vulns found in their formally verified code more than a decade after they completed the verification.
What are your thoughts on SEL4, is it really a breakthrough it is made to be in success of formal verification? Is there a way for users/administrators deploying it to verify themselves authors' claims? Or is it too difficult? I am afraid the latter...
In 2004 Peter Gutmann in his thesis/book criticized the hype around effectivity of formal methods in computer security [1]. Has the situation changed?