Fadlangs in base.

Holger said:
Thanks! Valid points, indeed. I was shocked when I learned (rather late in my life) that signed integer overflow is undefined behavior in C. It is easily catched in Assembly, but not in C, where you need some compiler-specific __builtin__add_with_overflow_checking stuff.
Click to expand...

Integer overflows are nasty bugs, and a good chunk of security bugs are based on them. Of course most of the Algol-like languages don't have checking either. In C++ you can at least make a new integer class where you use assembly fragments to insert a check. Not that anybody is actually doing that.

Another notch for Lisp.
 
Holger said:
Why are training, time-tested idioms and good coding standards not enough?
Click to expand...
time-tested for decades, yet, if you read the commit logs or svn-src-head, you'll notice there's barely a week we don't discover some hard core bug in the used-for-decades code. We want unit test, integration tests and regression tests, not "smoke tests", even if the smoke test ran for decades.

cracauer@ said:
No integer overflow checking, not even optional. No array bounds checking, not even optional.
Click to expand...
Actually there is: clang's address sanitizer catches these if you're daring enough to enable it.

Decent test coverage on the other side catches these kind of bugs, and it's lack is a source for far more and more troublesome bugs then those caused by C inconveniences.

C projects tend to have the worst test coverage among all, usually on the claims that something "could not" be tested.
 
Alain De Vos said:
About C. How many percent of the freebsd kernel is written in C. And why ? Offcourse nobody is 100% perfect.
Click to expand...
Given the size of the freebsd-doc repository, which qualifies as both code as well as FreeBSD kernel, in comparization to the size of the sys subdirectory of the freebsd-src repository, which is where the C sources of the kernel reside, it is safe to assume that our kernel is mostly written in html these days :P

That said, the amount of "actual" C "written" content is both debatable and difficult to measure. On one side, C allows for multiple statements in a single line of code, allowing C code to have a higher entropy (content density) then code written in languages that don't allow it, therefore the amount of C written code is higher then the lines of code might suggest. While our coding style states that multi-statement lines SHOULD be avoided, it's highly common nevertheless, especially in the historic parts of the code. There also is C code, either in pure form or as templates, within other languages' source files, that will be used to generate actual C code at compile time, which will then be fed to the C compiler. C code that is part of some cat<EOF games in a shell script basically is C code, even if it's in a shell script, and that could be argued to allow the amount of C content in the kernel to be considered higher then the line/byte/whatever ratio of the C file content to the whole repository.

In FreeBSD, the foreign language subcode is kind of neglectible when considering the amount of C code found in bison or perl scripts or the likes, however it's quite an thing the other way around: We have lots of C files containing inline assembler and array (or inline assembly ".byte") encoded opcode blobs that are not C even if though they are part of a C source file. Instrinctins kind of are C but at the same time kind of are not C, because while we _could_ provide a C written implementation there transparently, we don't, so instrinctins are just another way to encode assembler code inside C sources, and this can be argued to degrade the amount of C written content in the kernel.

Then, there is C inheritage considerations. A string constant in a source file isn't real C, and it could be anywhere else, too... probably it would be better off being elsewhere anyway. But string handling is such a particular weakness of C that frameworks and conventions were designed to (partially) overcome this weakness, and these frameworks have spread far beyond the C source code: If you rewrite the printf(1) command line tool in rust, go or javascript, you are basically writing a C application, even if you don't write a single line of C, as the whole purpose of that application is to conform to C.
 
kpedersen said:
Thats why C++ was created:

Code: 
std::non_copyable<std::arg_wrapper<boost::enable_signed<int> > > value;
value.lock().nonconst_iterator([=] { ++self; });

Much better. Completely immune to undefined overflow.
Click to expand...

Trying to solve all the problems with an inflexible language by piling on more syntax for 30 years is not a universally winning strategy.
 
cracauer@ said:
Trying to solve all the problems with an inflexible language by piling on more syntax for 30 years is not a universally winning strategy.
Click to expand...
I suppose perfection is the enemy of good.

C++30 could just break compatibility with C (which i.e Go, Rust, etc never had in the first place) and avoid the additional syntax. I don't think that is a winning strategy either.
 
kpedersen said:
Much better. Completely immune to undefined overflow.
Click to expand...
Completely immune to readability, too. C++11 allows the template-closing '>' characters to be concattenated to each other without space characters between them, btw, so you can symetry betwen opening and closing the template '<' and '>'.
 
kpedersen said:
C++30 could just break compatibility with C
Click to expand...
Or it could implement the useful stuff of the modern C standards, such as designated initializers.

It can also break compatibility, not to the API of C, but the the ABI of previous C++ compiled object files and libraries, and once it does it could implement smart pointers that actually work to replace the meme that C++ smart pointers are right now.
 
kpedersen said:
Thats why C++ was created:

Code: 
std::non_copyable<std::arg_wrapper<boost::enable_signed<int> > > value;
value.lock().nonconst_iterator([=] { ++self; });

Much better. Completely immune to undefined overflow.
Click to expand...
Important announcement: The IOCCC just took place. The lines above would not even have rated a honorable mention. IOCCC = International Obfuscated C Code Contest. I highly recommend reading that code, it is very amusing.
 
xibo said:
Completely immune to readability, too. C++11 allows the template-closing '>' characters to be concattenated to each other without space characters between them, btw, so you can symetry betwen opening and closing the template '<' and '>'.
Click to expand...
Indeed. I was hoping someone would pick up on that as the *only* problem with the snippet to take away! XD


xibo said:
to replace the meme that C++ smart pointers are right now.
Click to expand...
Agreed. I think much of the hosted+STL is a bit of a dead end to be fair in terms of safety. The C++ "freestanding" standard and a rethink is certainly something I would like to see "modern" C++ attempt in the future.

At work we have a hand-rolled smart pointer (like its the late 90s again!). However ours works very differently to what is currently the norm (unique/shared/weak just don't do enough to prevent memory errors via dangling this. I think its safe to say that they solve leaks fairly well but not errors, they actually exacerbate them).

Currently looking for a defense related software conference to submit a paper to but CFPs are quite seasonal. We will have a stand at DSEI in the coming weeks so will hopefully find some good avenues there.
 
It's only for the bootloader. So no big deal.
4th language is 55 years old.
Probably it's there for historical reasons.
Why not switch completely to lua ?
 
Alain De Vos said:
It's only for the bootloader. So no big deal.
4th language is 55 years old.
Probably it's there for historical reasons.
Why not switch completely to lua ?
Click to expand...
As far as I know, on resource-limited environments like embedded devices, even the size of loader matters, and lua loader is larger than forth loader.
If I understand correctly, this is because forth loader is still alive and can be chosen by admin.
Another concern would be "customized loader scripts". If the admin is familiar with forth but not with lua, it can be an issue.
 
T-Aoki said:
As far as I know, on resource-limited environments like embedded devices, even the size of loader matters, and lua loader is larger than forth loader.
Click to expand...
The problem with the loader, in the first place, is that it's quite a troublesome software to system test to begin with, and nieche hardware frequently not behaving the way it's documented to do doesn't improve the situation, either. Many of our Tier 2 systems also have no reference implementation (emulator) at all, or require to sign 5 dozen NDAs to get it. As a result, that loader breaks something almost as often as it gets commits to it.
If we were to rewrite it in, say C, half of our tier 2 platforms would be rendered unbootable.
 
You must log in or register to reply here.
Back
Top