Microsoft Open-Sources 'Checked C,' A Safer C Version (softpedia.com) 208
An anonymous reader writes from a report via Softpedia: Microsoft has open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues. As its name hints, Checked C will add checking to C, and more specifically pointer bounds checking. The company hopes to curb the high-number of security bugs such as buffer overruns, out-of-bounds memory accesses, and incorrect type casts, all which would be easier to catch in Checked C. Despite tangible benefits to security, the problem of porting code to Checked C still exists, just like it did when C# or Rust came out, both C alternatives.
Hasn't this been done before? (Score:3)
Some old GCC? (Score:4, Informative)
Long long time ago (~2000?) I used GCC's bounds checking feature.
If I recall correctly, I had to compile my own GCC because it was the only way to enable it.
Re: (Score:2)
There was an effort at Cornell University to produce 'Cyclone'. It required a modifications to gcc.
If MS made this a 1st class citizen of Visual Studio it might gain some traction. That it's using LLVM sounds intriguing - might MS be switching to the platform for its compiler suite?
Re: (Score:2)
These changes are, indeed, very similar to Cyclone. The main difference is that they're not an all or nothing approach. You can still do unsafe things in Checked C, you will just be able to audit your code to see where you do them and gradually apply them. The lack of an incremental adoption path was probably what killed Cyclone.
As to Microsoft using LLVM, current versions of Visual Studio support all four combinations of the MS and Clang front ends and the MS and LLVM back ends. I don't think that the
Microsoft Checked C (Score:5, Funny)
Re:Microsoft Checked C (Score:5, Insightful)
no no no.
MS wouldnt put telemetry as a header. You can choose not to include, or worse, edit, header files.
no no. The CC will hard link "telemetry.o" to every project at compile time, and wont have any switches to disable that behavior. Don't worry, they use digital signature checking to be sure that telemetry.o is the object file it expects it to be. Cant have untrusted objects in the linking phase now.
Re: (Score:2)
Re: (Score:3)
Oh hush AC, Let us have our fun. ;P
Re: (Score:2)
C? C++? C#? Checked C? (Score:5, Funny)
That's it, I've had enough. I'm going back to Turbo Pascal.
Ambiguity (Score:2)
I'm confused - is Microsoft reinventing C++ or reinventing Java? I can't tell which decade from the last millennium they're trying to drag us back to. (Maybe as far back as when they were considered a reputable software company?)
Re: (Score:2)
C++ solves a lot of safety problems with C. Smart pointers can deal with most dynamic memory problems, and using the C++ string and container classes you can avoid most buffer overflow problems.
Solve the problem in hardware, have done with it. (Score:5, Interesting)
Re:Solve the problem in hardware, have done with i (Score:5, Informative)
That's the right direction. Apple already has a pretty good version of it. (See below.)
Bounds checking C like this now is weak and very, very late:
https://gcc.gnu.org/ml/gcc/199... [gnu.org]
https://www.lrde.epita.fr/~aki... [epita.fr]
http://blog.qt.io/blog/2013/04... [blog.qt.io]
http://valgrind.org/docs/manua... [valgrind.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.
http://www.cocoawithlove.com/2... [cocoawithlove.com]
Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.
I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.
Re: (Score:2)
Re: (Score:2)
Queue the idiots screaming that Apple stole it from FreeBSD now
Is it "stole" as much as "used under license"? Darwin is FreeBSD's userland on a Mach-derived kernel.
a pointer to VLA is a bounded pointer type (Score:5, Informative)
The funny little known fact is: C99 already has a bounded pointer type: A pointer to a variable-length array.
void foo(int N, char (*ptr)[N]) // undefined behaviour
{
(*ptr)[N + 3] = 10;
}
Using the undefined-behaviour sanitizer, you can also have the compiler add automatic checks.
Re: (Score:2)
Sorry, a VLA has nothing to do with stack vs malloc. This is a common misconception. The pointer in my example could refer to memory on the heap.
Re: (Score:2)
All caps by many conventions means a precompiler define, this is a common way to set static buffer sizes in case they must change later.
Pascal? (Score:2)
So checked C is simila to Pascal?
Re: (Score:2)
It's about time (Score:2)
It is absolutely astonishing that it has taken _this_long_ for someone to make these basic fixes to C.
Re: (Score:2)
It's more surprising that people think C needs "fixing". C is just a toolbox with almost no restrictions - so you have to be careful using it. Once you start adding restrictions to your tools, you end up with other problems.
Put another way, C is almost the ultimate in coding freedom (probably only assembler is more free, but is not quite as portable as C) so requires lots of responsibility. Adding in checks to a language does free the programmer from responsibility but necessarily comes at the cost of som
AI (Score:2)
I imagine at that point everybody would be using a programming language like Go or Python that emphas
C# fails again (Score:3)
Another indication that M$ recognizes that .NET and C# have failed.
I know what the checked stands for (Score:2)
"Checked C"? (Score:2)
And, so, how is this different from lint?
For that matter, none of all the C I used to write ever had buffer overflows, or memory out of bounds, etc. Of course, I wasn't right out of school when I wrote it, nor was I lazy... so, for example, I almost *never* used while/wend - overwhelmingly, it was for/next, with *LIMITS*. After some early C programming bugs that I fixed, I started, more and more, using strncpy.. And I *checked* the return from malloc.
Re: (Score:2)
I never used while/wend or for/next in C either. They're not C language constructs.
Re:What a Waste of Time (Score:5, Informative)
strcpy_s is part of the C11 standard, and it was a library addition, not a language change.
Re: (Score:2)
All these noobs preoccupied with the "security" of libc string function... nobody use the libc string function not because they are insecure, but because they are bad. They are also trivial to implement if you really need them. Anyone that need to process text will build a proper parser.
Except nearly all parsers will use them in some form.
String are the least important aspect of any programe... except helloworld.c which is all about string and accomplish nothing.
If you think string parsing, manipulation is the least important aspect, then it is very obvious you do not actually do any programming any more. Inputs are more and more becoming linked with string parsing, gaining larger and larger influences over RPC APIs since XML and now JSON.
Re: (Score:2)
Meh, I wrote a functional kernel-mode XML parser used in production for a job a few years back. Didn't use a single library string function, which was the point here. As the GPP said: anyone that needs to process text will build a proper parser.
memcpy is different: it's full of surprisingly complex optimizations. But memcpy_s is fucking stupid.
Re: (Score:3)
There's also a Generalized Checked C - GCC for short.
Re: (Score:2)
Re: (Score:2)
Up pops Clippy - "It looks like you're voiding a pointer!"
Re: (Score:3)
Up pops Clippy - "It looks like you're voiding a pointer!"
Hey, John, It looks like you want to write some spaghetti code dereferencing Null pointers. Would you like help?
Re: (Score:2)
Re:C99 and C11 (Score:4, Insightful)
This won't gain traction until it's compatible with the C99 and C11 standards.
how the heck are you gonna shoehorn this into standard C? We are talking about restricting what the programmer can do, there's NO WAY you can achieve bounds checking behavior without breaking existing C behavior, because "broken" programs with bounds checking problems are "perfectly acceptable" C.
You CAN use a bounded pointer, or unbounded (Score:2)
They allow for both by introducing a "bounded pointer" type in addition to the old style pointer. If you want to, you can still create a buffer overflow using a char *. Or, you can choose to a char 256* and access to it won't overflow 256, it'll generate an error.
Re: (Score:2)
A bounded pointer-type already exists: char (*ptr)[256];
That reserves memory, it doesn't add bounds checki (Score:2)
That declares that ptr is a pointer to a character, and reserves memory at that address for 256 characters. It does NOT prevent one from accessing ptr[312] . (Though a compiler MIGHT catch it if 312 were a literal.) By the C standard, the behavior when attempting to access ptr[312] is undefined, put it would normaly access whatever happens to be at a memory address 66 characters past the end of the ptr array.
The Microsoft extension adds a type with run-time bounds checking, so trying to access ptr[312] wi
Re: (Score:2)
Re: (Score:2)
In the example I gave, the size is encoded in the type. This makes it simple and cheap for the compiler to add bounds checking (which can also often be optimized away if it can prove that the access is not out-of-bounds).
Re: (Score:2)
Re: (Score:2)
And (ptr + 20) is even worse since it's completely missing dereferences.
Your printf example is correct though, but not relevant to the current case.
Re: (Score:2)
This does not reserve memory. This declares ptr to be a pointer to an array of length 256. This is exactly what a bounded pointer is. And yes, compilers can sometimes detect out-of-bounds accesses at compile time (not only for literals) and because out-of-bounds accesses are undefined behavior, there are free to add run-time bounds checking when the pointer is de-referenced. And this is exactly what the undefined-behavior sanitizer for clang and gcc does if you use it. I know, because I fixed this for gcc
Very interesting, thank you. Might use the flag (Score:2)
That's very interesting, thank you. Sometime I might use -fsanitize=undefined. Since most software is network-bound or IO-bound, I suppose the cost would be minimal?
> I know, because I fixed this for gcc because it wasn't working.
It's always good to hear from someone who definitely knows.
Re: (Score:2)
Re: (Score:2)
IIRC, accessing memory outside of a restricted area is undefined behavior, meaning that an implementation can do anything and remain conforming, and that a future standard could define some behavior without changing the set of valid C programs.
Re: (Score:3)
I thought visual studio *did* issue deprecation warnings when compiling use of certain 'considered harmful' practices and libraries.
At least that was my experience in maintaining the code of a C hacker who had left the programming team. But not being an expert in the language, I wasn't sure if the compiler was being overly pedantic or whether removing all the compiler warnings might fix the issues we were having or break in new ways!
Re: (Score:2)
Visual C++ depreciated a number of fundamentally unsafe C library functions, replacing them with _s versions, does some rudimentary analysis of stack and array safety, and a few other things, if you compile with the Security Lifecycle Development checks. [microsoft.com]
Re: (Score:2)
Unfortunately while it includes the fundamentally unsafe ones like gets(), it also deprecates a bunch of functions which are not fundamentally unsafe, such as the simple and super common strcpy (which is just fine if you know there is a null byte within the buffer length, generally because you as the programmer put it there).
The solution they use is also pretty bad, adding a buffer length parameter to the function is useless in practice as it still lets you overflow the buffer by getting this wrong, and it
Re: (Score:2)
> Visual C++ depreciated a number of fundamentally unsafe C library functions
It made them worth less money?
Laugh it up. Someday you'll get old and C-nile like me.
Re: (Score:2)
There's no quotes around perfectly acceptable.
But you are correct, this seems impossible to be compliant with C.
Obviously, it is not trying to. In fact, it is trying to be semantically different from C in very specific areas, for very specific reasons and for a very specific audience.
Re: (Score:3)
it will never take off, because breaking those rules lets programmers do "neat tricks", which they wont be able to do with type-strict conventions.
when there is an alternative that allows laziness, expect that option to be vastly more popular.
Re:C99 and C11 (Score:4, Interesting)
And sometimes, the weird behavior is actually the right behavior - even when compilers disagree. Remember the issue a few years ago when it turns out almost all the sshkeys generated on any debian (or debian-derived) system were highly predictable ? It happened because the random-number generator in openssh was throwing a compiler warning for "considered dangerous" handling of a pointer - except that, in that case, it was a critical part of the entropy feed. Some debian packager wrote a patch to "fix" the code to proper bounded behaviour... and ended up castrating the entropy feeder function.
It no longer threw a warning - it just led to one of the worst security problems in Linux history and took weeks to recover from when it was discovered years later and everybody had to regenerate their keys.
Re: (Score:2)
That's broken & unportable:
Q: How do you port it to a safe-access-only language that zeroes allocations?
A: By using an entropy source (random number generator).
Reliance on undefined behavior is asking for failure. Running code that does so is a security risk.
Re: (Score:2)
It might not take off among hobbyists, but MISRA-C is very popular among developers of safety critical applications.
I would not say "popular", but we do use it.
Actually, "MISRA C" is not a language specification, rather it is a set of "best practices". The document states that the rules there in are guidelines and that it is expected that real projects will need to "violate" 1 or more guidelines to achieve practical, understandable and maintainable code. And that when such "violations" are made, they be documented and properly justified.
Unfortunately, some mangers insist on strict adherence to the MISRA rules. This leads
Re: (Score:2)
It also needs a very wide variety of back ends. x86, powerpc, arm, cortex, avr, SH, 68K, etc. People doing C are all over the board with parts and not sticking with only Windows.
Re: (Score:2)
Microsoft have said they are working on a clang/llvm port that supports this so that should cover everything LLVM supports including ARM, MIPS, PPC, SPARC, x86, x86-64 and more. And with the spec being open, it should be possible to build a GCC frontend for this that can take advantage of all the many back-ends GCC has.
Re: (Score:2)
This won't gain traction until it's compatible with the C99 and C11 standards.
There is a whole world of development out there that exists outside of such circles. It is obvious that the target market is somewhere else (Windows-specific systems development for instance.)
Re: (Score:2)
Re: (Score:2)
Depends how you define "widely".
There are so many languages that are "more" used than C, I really wonder if I would put C into the "widely used" category.
Re: (Score:2)
By "so many" you mean... 1?
http://spectrum.ieee.org/compu... [ieee.org]
Re: (Score:2)
The link does not show how widely languages are used :D
Perhaps you should read your link?
Re: (Score:2)
In his defense, if it's still popular today and older than the others on the list, it is probably the most widespread.
Popularity + time = widespread use
Re: (Score:2)
Most people that once used C and still stick to "close to the metal" use now C++. .Net based languages like C# or managed C++.
The rest of the world moved on to Java/Scala and
"Simple C" is only still used in very restricted embedded devices.
C is simply not productive enough for a programmer when you have more productive languages available.
Productive as in features by amount of lines of code and speed how you implement those features.
If you forced me to program in C you had to agree that every feature that I
Re: (Score:2)
"Simple C" is only still used in very restricted embedded devices.
That's not a small userbase. That's a frikkin' yuuuuge userbase. In fact, this alone probably puts in on top. Your car is programmed in C. Your HVAC is programmed in C. Your gas pumps are programmed in C.
Also, let's not forget that the computer your typing on? Its kernel is written in C. Regardless of your OS is or what its supporting libraries are written in (C++ for Windows, Objective-C for MacOS, and Linux uses you-can-guess). The kernel is in C.
C is simply not productive enough for a programmer when you have more productive languages available.
Productive as in features by amount of lines of code and speed how you implement those features.
If we count productivity in the size of the compiled binari
Re: (Score:2)
That's not a small userbase. That's a frikkin' yuuuuge userbase. In fact, this alone probably puts in on top. Your car is programmed in C. Your HVAC is programmed in C. Your gas pumps are programmed in C.
Or in C++ as I pointed out.
And no, that is not a userbase. We are talking about programmers, or lines of code or devices sold.
Its kernel is written in C. ... and I would not wonder if some are written in C++ and not in C ...
And? How many kernels do exist? 100? I can count less than 10 I fear
If we count prod
Re: (Score:2)
Most people that once used C and still stick to "close to the metal" now use C++. .Net based languages like C# or managed C++.
The rest of the world moved on to Java/Scala and
"Simple C" is only still used in very restricted embedded devices (restricted as in very low memory footprint etc.).
C is simply not productive enough for a programmer when you have more productive languages available.
Productive as in features by amount of lines of code and speed how you implement those features.
If you forced me to progr
Re: (Score:2)
Yes I'm serious.
Neither is it amoung the top 3, regardless which metric you use: lines of code produced per year, numbers of developers sought for projects, amount of money earned or payed in using it.
It usually barely makes rank 5 or something with a "market share" of 10% to 15%, with Java at probably 30%, C# the same, C++ slightly higher than C and PHP and Python in front of C. That puts C down to: well as I said in the intro: 10% - 15%.
And that number hardly can be called "widely used", sorry. If you wan
Re: (Score:2)
Re:checked C (Score:4, Informative)
and all of it is C.
That is wrong.
All embedded systems I was involved in the last 10 years used: C++
And still half of all embedded systems build in Avionics use: Ada
For example, the Freescale line of coldfire processors all use a tool called codewarrior.
You clearly have no idea what you are talking about.
Codewarrior is an IDE!!! It uses what ever compiler you put behind it. And usually that is a variation of GCC.
Codewarrior is an IDE that was originally written by Metroworks for MAC OS, an IDE focused solely around C++. The fastes C++ compiler for Macs around that time and later acquired by Freescale.
http://www.nxp.com/products/so... [nxp.com]
Scroll down to: "Unlimited C/C++/EC++/cC++ Compiler and Debugger for HCS12(X) derivatives and XGATE module "
C has been ported to every instruction set that has ever been invented, and there are more C compilers in the world than there are Java, C++ and Python compilers / interpreters combined.
How is that relevant to the points I made? (If it is even true)
The IEEE keeps a list of the top languages, and their list includes the embedded space which is ignored by these other lists. C and C++ take the #2 and #3 spots, which accurately reflects the underlying reality. ... not for smart watches, not for iPads, iPhones, Samsung Galaxies or any other Android device.
For embedded programming!!! Yes. Not for business code. Not for web pages
If one hires a developer because he has used Codewarrior and ditches one who used Code Composer Studio instead: he is an idiot.
If I had to hire an embedded programmer I would insist on seeing some C/C++ code and would not care what kind of tools he used.
Re: (Score:3)
Slight correction from a guy who sent quite a few dollars to Metrowerks in the 90s:
Codewarrior was originally a C environment, and C++ was added later, in fairly slow steps towards "standard" C++ (which meant ARM (Annotated Reference Manual) conformance until the ISO standard took shape).
Re: (Score:2)
I considered to by Metroworks Codewarrior. But sticked with ThinkC (later Symantec C/C++).
ThinkC was a C++ subset with single inheritance and no templates, Mac only ofc. Symantec kept it a while alife. Not sure when they discontinued it. However ThinkC came with an application framework making it extremely easy to develop for Macs without knowing the Mac OS APIs.
Did not even remember that meaning of ARM ;D
Re: (Score:2)
The long term website tracking popularity (as well as you can do that for programming languages) is at http://www.tiobe.com/tiobe_index
C is pretty much always 1 or 2 in the list, and notice how it has twice the ranking of the third in the list (C++... which owes much of its popularity to the ability to compile most C programs). C is a very popular language, and is pretty much the language of choice whenever you need to do something novel, involving hardware, or care about execution time. It is not usually
Re: (Score:2)
I never noticed C under the first three on tiobe, but I'm not tracking it constantly. Most of the time it was behind Java, C#, PHP and Python.
(C++... which owes much of its popularity to the ability to compile most C programs)
That is nonsense.
C++ has its popularity because it is the better C. And: it does by far not compile old school C code.
Then again n current tiobe: C has barely HALF of the rating of Java.
So it simply proves the point I made in the first post in this article: with 12 points from 100, it
Re: (Score:2)
C++ will not compile K&R C. It's fairly compatible with C90, the first C standard, in that it's easy to change a C program to compile in C++.
Re: (Score:2)
It has never been lower than position 2. It has been first or second on that list since they started tracking it, as you can see if you scroll down a little bit for the chart over time (which goes back 15 years on that page).
If all of your jobs involve javascript, that likely makes you a web developer. Using some web frameworks to put together websites is about as far away as you can get from systems programming, so of course nobody is asking you to write a bunch of C code. It is not your profession, and
Re: (Score:2)
The vast majority of important code is written in C
Yes, that are lots of people claiming.
No one showed any evidence.
I will also throw out there that I do a lot of code review, and the C programs I am sent have by far the lowest defect rate of what I review ... bytes, it seems programmers don't care
I did not do that for a while. However most C programs I have seen, especially embedded, have the highest defect rates asumeable. With code only executed from rom and ram in the size of 4 or 16 bytes not kB or MB
Re: (Score:2)
As I said, I doubt it :D
And no one has numbers anyway, so a discurse is mood.
Re: (Score:2)
Re: (Score:3, Interesting)
It baffles me the sheer number of warnings some projects generate on compilation. Sure many aren't relevant, but some are, and if your code generates bucketloads the chances of missing the important ones is high. And really: how hard is it to do simple things like putting extra braces around if statements where you really do want to do an assignment, properly casting things (signed -> unsigned for example), or typing (void) foo; when you really want to include argument foo in the function arguments eve
Re:Better get used to it... (Score:5, Insightful)
As yet, nobody has made an OS that isn't C at the bottom. There's a reason for that. Although there are projects that claim it's now possible, not one major operating system uses them for kernel programming.
And wrappers like this have existed since the first day of C. You can always wrap your own memory and pointer management functions and structures and just expect people to use them. They come with a performance cost, and wrapping C means people can only use your wrappers. Even this, which claims compatibility, basically just introduces two new pointer "types" which can't be dereferenced in the normal way.
It's not that this has been impossible forever and people are only just going "Oh, maybe we should do something". It's been this way because there are things that you need to take account of still. And though security is certainly a high-priority, a system that runs dog-slow, isn't compatible with other APIs, has to have tricks all over it to make it work, and ultimately still has to end up with hardware pointers where the bounds are set by the programmer (as here) means that it won't get used at all.
There's a reason that even "theoretical" OS like MINIX still use C and pointers. At the OS level, hardware access needs unbounded pointers or pointers that only the programmer knows the bounds of. Basically, bang, security problem if they use them wrong.
Even ordinary applications made in pointer-managed languages have to - by definition - include more checks and code than those that don't. I'm not saying those checks aren't worthwhile, or don't stop security problems, but there is still yet to be a serious OS or even low-level drivers written in anything other than C.
And people speak as if, if we were to all just move to Rust or whatever (which also includes its own pointer types including a special insecure "unbounded" pointer - wonder why that is even in there, hmm?) that all the security problems would magically disappear. Unfortunately it's not like that.
It's about eliminating human error and there's a lot that can go wrong with pointer arithmetic and lack of checks. But that human error is present whether or not a pointer is used. Most of the time the problem is lack of bounds checking - that, in any language, can lead to serious problems like crashes, acting on incorrect data, getting into infinite loops, etc.
The problem is that the one part you NEED that kind of balance, deep in the kernel rings where you're using drivers and low-level memory access outside of the normal protections, you don't have it available as the hardware needs real pointers to be manipulated in order to operate.
Comment removed (Score:4, Informative)
Re: (Score:2)
Technically, of course you're correct.
However, are we suggesting that assembler is a better memory manager? Because it's literally the bottom of the pack, with C only just slightly above it because it actually include a malloc function.
And Cosmos pretty much only works in VMWare and doesn't even have a single hardware video driver (my exact comment - when you need to start interfacing with hardware, it becomes almost impossible to make any guarantees about the pointers you need to play with) - strange that
Re: (Score:2)
it becomes almost impossible to make any guarantees about the pointers you need to play with) - strange that.
That is nonsense. To access hard ware in 99.9% of all cases you have a fixed pointer pointing to the "I/O port" of that hard ware. The pointer never changes, you don't do any arithmetic with it etc.
And all languages that don't run in a VM support such pointers, e.g. in Pascal you write:
aLongWord : long [$000EF0002], some Pascals have an "absolute" keyword that takes an address, and basically all Pasc
Re: (Score:2)
I have no idea how you would try to program a PMMU in C.
Any program requiring a processor feature not exposed by the definition of the C language can be written in a language that's a superset of C with either intrinsics for that feature or inline assembly. Intrinsics [wikipedia.org] are more involved to implement but might be safer in the sense that more things can be statically proved about their behavior.
Re: (Score:2)
Re: (Score:2)
As yet, nobody has made an OS that isn't C at the bottom.
Riiight. [wikipedia.org]
Re: (Score:3)
Of course their were the lisp machines: https://en.wikipedia.org/wiki/... [wikipedia.org]
Re:Better get used to it... (Score:4, Interesting)
As yet, nobody has made an OS that isn't C at the bottom.
What nonsense.
Perhaps you like to google a bit or read wikipedia? Mac OS e.g. was written in Pascal. Other OSes are written in Forth, Java, Oberon, Modula II. There are plenty of OSes you never heard about written in Languages you never heard about.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That and if you need to port your code to other architectures, such as x86 vs. x86-64 vs. ARM vs. MIPS, you can recompile C with only a minor loss in runtime speed due to loss of effectiveness of micro-optimizations.
Re: (Score:2)
Re: (Score:3)
You apparently haven't looked at the output of C compilers recently. The output is less and less predictable from looking at the C code.
The biggest issue with C at the moment isn't actually bounds-checking (although that would be nice) -- it's the fact that it's a minefield of constructs which look perfectly sensible but are in fact "undefined", in which case the compiler is authorized to do
Re: (Score:2)
Re: (Score:2)
For instance, the C standard explicitly states that all pointers point to valid memory, and that having a pointer that points into non-valid memory is "undefined".
Define an "invalid pointer" value then?
Among the many uses of C is OS and Boot Loader programming, and in those cases the value "0" is still a valid memory address to use. IOW, there are some areas of programming where there is no invalid value. therefore you can't define what is non-valid and what is valid, therefore it is undefined. These areas are also a primary target of operation for the C Programming Language.
For the C language itself, there probably isn't really anything that could be improved
Singularity OS (Score:2)
No-one sensible is going to write an OS or low-level driver in C#.
Singularity [wikipedia.org] was written in a variant of C#, using the .NET CLR's safety model.
"Singularity authors aren't sensible"? No true Scotsman.