9 ms·
C11: A New C Standard Aiming at Safer Programming
- nonamegiven 14y ago"Finding C99-compliant implementations is a challenge even today." "Originally, all of the bounds-checking libraries were developed by Microsoft's Visual C++ team. The C11 implementation is similar but not identical." Picking a nit, but shouldn't this say "The C11 standard ..."? If C99 implementations are hard to find, I'd think it would be more so for C11. Are there any C11 implementations? Or do you just pick the implementation and libraries that implements that largest set of C11 that are important to you?
- cjg_ 14y agoClang supports some parts of C11, see http://clang.llvm.org/docs/LanguageExtensions.html#c11 http://clang.llvm.org/docs/LanguageExtensions.html#c11 for details.
- CedarMadness 14y agoThe big problem with C99 was that MS refused to implement it. If C11 is going to take off, it will depend on MS updating their C compiler. Previously they have said that they don't support C development on Windows except on the device driver level, and would prefer everyone use C++ or one of the .NET languages, so I'm not hopeful about C11's chances.
- AlexeyBrin 14y agoClang has implemented a good chunk of C11, I would say you can use C11 on OS X, iOS, Linux etc ... You can even use Clang on Windows if you need (MinGW, Cygwin or compiled with Visual Studio). I'm not sure if you can integrate Clang in VS for example, or if it is possible to access the OS C libraries from Clang.
- stephencanon 14y agoWhy? No serious C development happens with MSVC today, and yet C is still one of the most widely used programming languages. The world has long since moved on, and C11 will be adopted by gcc, clang, icc, ibm's compilers, pelles and others. As a professional C programmer, I really couldn't care less whether or not Microsoft decides to implement C11 or remain in the dark ages. That ship sailed years ago.
- saosebastiao 14y agoI'm not seeing this as much of a problem. Windows is a dying platform because of a multitude of bad decisions like these. If they choose not to implement it, less software will be made for Windows, accelerating its demise.
- rbanffy 14y agoPeople will continue writing software for windows for as long as it remains the dominant platform. What happens is that they'll use other languages such as C# (which is perfectly fine for them)
- saosebastiao 14y agoOf course people will continue to write software for the platform. I never said otherwise. But there is a ton of software being written right now that doesn't target Windows, with no plans to target Windows. The only way Windows users will ever be able to use that software is if Microsoft makes it easy enough to port. The nail in the coffin will be when most of the games on Steam do not work in Windows. With most business software becoming web-based, the only holdouts left will be old businesses locked into their enterprise crapware.
- cmccabe 14y agoA few adventurous folks wrote a c99-to-c89 compiler, to solve the issues with MSVC. https://github.com/rbultje/c99-to-c89 https://github.com/rbultje/c99-to-c89 (see http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav/ http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...)
- deleted 14y ago[deleted]
- wladimir 14y agoIt's sad that C99 was never widely adopted. It's 2013 and MSVC still doesn't implement it. I really like the constructs that were added, especially with regard to named structure and array initialization. It manages to make programming in C just that little bit friendlier, more powerful and less over-verbose.
- stephencanon 14y agoIt's not clear what you mean by "never widely adopted". With the exception of MSVC, are there any mainstream C compilers that don't try to follow the C99 spec?
- sageikosa 14y agoMicrosoft doesn't make a C compiler. They have a C++ compiler that can also compile C90.
- wladimir 14y agoSorry that I was unclear. I always use a C99 supporting (gcc/clang) compiler for my own C projects. However, the problem is that because MS doesn't adopt it, a lot of companies and projects still have coding standards that forbid the use of C99 constructs. This because of the (percieved) need to compile for Windows with MSVC some day. So MS not adopting C99 is a problem for adoption, even though most compilers support it fine.
- pbiggar 14y agoI find it interesting that this snuck up on me. I heard dozens of things about C++0x for years before it happened, but this seems like its already been published and this is literally the first I've hear of it.
- AlexeyBrin 14y agoThe article is about C (as in C11 standard) and not about C++ (as in C++11).
- Scaevolus 14y agoThere was a lot of hype about C++0x. There has not been much about C11.
- stingraycharles 14y agoWhich is exactly what the OP is talking about. There was a lot of buzz about C++11 before it was released, yet there was very little buzz about C11 (or at least, not something the OP noticed).
- stephencanon 14y agoWhile the C++ community is gossiping about language features, the C community is busy writing software to get things done. =)
- Nursie 14y agoWhile this is flippant (and amusing) there's an underlying truth here somewhere - I've really not met many C programmers who care about new language features. C++ folks do seem to care a lot about which features of boost are going to be folded into the language spec and runtimes and what else has been dreamt up for their baby, and how they're going to be able to be more efficient, safer and gosh-darnit just all-round smarter in future. C programmers mumble something about being busy and already having the tools they need to do everything, though (grudgingly) that VA_ARGS preprocessor extension from '99 was quite handy I suppose... (I'm a C programmer by trade and history, working on C++ at the moment, just in case I pissed anyone off enough to start a holy war :)
- vor_ 14y agoGeez, is there a single non-troll comment on that website?
- mjn 14y agoThe removal of variable-length arrays is the main thing from C99 I miss in C11 (though it seems compilers can continue to support them if they wish). Imo they're fairly elegant in many scenarios, and without them, C programmers tend to make heavier use of magic #define'd array sizes in order to retain the notational convenience of auto arrays.
- simias 14y agoI write C for a living and I've never ever used that feature. I don't think I've seen it used outside of C99 tutorials as well. Can you give us a practical example of some code where variable-length arrays prove really useful?
- mjn 14y agoI've mostly used them in two cases: 1. Multidimensional arrays where the sizes are quasi-fixed but not known at compile time. Comes up in various kinds of grid-simulation code, for example. You could malloc() in this case, but then you lose the notational convenience of 2d arrays. 2. Refactoring code that uses #define'd constants, to take runtime instead of compile-time parameters. For example, a common first-pass to said grid-simulation code is to have some WIDTH and HEIGHT magic numbers, which you might later regret and want to make into command-line parameters. Refactoring is trivial if you have VLAs. It also seems cleaner (to me) semantically. I can see why, implementation-wise, classic C auto arrays required constant sizes. But from a slightly higher-level perspective, whether a variable is auto or not, and whether its size is a compile-time constant or not, feel like independent decisions. It feels particularly messy that you have different notation for arrays whose sizes are known at compile time; the syntactic sugar there has some rough edges. I also find it cleaner if explicit malloc()s are used only when something beyond boilerplate is going on, letting the compiler handle the boilerplate case of allocating/deallocating a conceptually block-scoped array of size N.
- jedbrown 14y agoI usually don't let them creep into the API, but I use them for convenience within a function that needs direct access to the multidimensional structure, i.e. void func(int M, int N, int P, double *a_flat) { double (*a)[N][P] = (double (*)[N][P])a_flat; // use a[i+1][j+2][k-1] instead of a_flat[((i+1)*N+(j+2))*P+k-1].
- dkhenry 14y agoI am not excited about any of the new features ( except many aligned_malloc) and I write C for a living. I think you get to a point with a language with C where I actually _dont_ want much change everything works just the way it is and we have dealt with its warts for decades. I am actually a little leery of the thread additions and the atomic additions. I feel that shouldn't be a part of the language specification and I would much rather see that incorporated at a higher level.
- stephencanon 14y agoFor those of us who do numerical programing, the new complex initializer macros are a huge improvement; previously it was quite painful to initialize complex values with an infinite imaginary part without resorting to non-portable extensions. It's a minor fix, but it's vastly better than what was there previously, and it's exactly the sort of change that works really well in C; incremental fixes that are carefully thought out and easy for both implementors and users to adopt.
- cygx 14y agoI am actually a little leery of the thread additions and the atomic additions. I feel that shouldn't be a part of the language specification and I would much rather see that incorporated at a higher level. What higher level? POSIX? Personally, I believe things like atomicity and alignment do belong into the language specification. Also keep in mind that the multithreading support as specified by C11 is closely aligned with C++11.
- jedbrown 14y agoPresumably you are familiar with Boehm's famous "Threads Cannot be Implemented as a Library" [1]. Meanwhile, pthreads require heavyweight OS involvement and implementing a simple spinlock requires inline assembly or non-portable compiler builtins. There is still no widely-used portable library of atomics (the Linux kernel is the most complete I know of, but their atomic support isn't trivial to extract for use outside the kernel, and it was only written for one compiler (gcc)). I'm definitely looking forward to stdatomic.h. Unfortunately, compilers are already mis-applying [2] the macros that are supposed to be available for determining the presence of thread and atomic support, so, as usual, configure tests are needed for everything. [1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
- frozenport 14y agoRestrict is part of the C99 standard
- jessaustin 14y agoIt's been a while since I used C very much, but news like this plus the great new 21st Century C, http://shop.oreilly.com/product/0636920025108.do http://shop.oreilly.com/product/0636920025108.do from Ben Klemens and O'Reilly has me reconsidering that. That book says those who complain the standard doesn't do enough should look at POSIX and libraries like GLib for help.
- AngryParsley 14y ago//C11, safe version of strcat errno_t strcat_s(char * restrict s1, rsize_t s1max, const char * restrict s2); strcat_s() copies no more than s1max bytes to s1. The second function, strcpy_s() requires that s1max isn't bigger than the size of s2 in order to prevent an out-of-bounds read: //C11, safe version of strcpy errno_t strcpy_s(char * restrict s1, rsize_t s1max, const char * restrict s2); Originally, all of the bounds-checking libraries were developed by Microsoft's Visual C++ team. The C11 implementation is similar but not identical. There are so many problems with this. Yet another slightly different string manipulation function? Why not standardize on one of the already existing ones, such as strlcat/strlcpy? I can see people making some big mistakes with strcat_s, since the size passed is the number of unused characters left in s1, not the size of s1. And strcpy_s can cause a segfault if given an s1max that is greater than the size of s2. Why not only copy up to the first null character? Also, these functions have the same name as the VC++ functions, but behave differently. In VC++, strcat_s takes the size of s1, not the space remaining. People are going to google for strcat_s, read the MSDN docs, and unknowingly add buffer overflows to their code. Finally, these functions have annoying behavior. If they hit the limits passed to them, they erase s1. No best-effort. No copy whatever fits. Just destroy the data in the destination string. strlcat/strlcpy solve all of the problems I've mentioned. See http://www.courtesan.com/todd/papers/strlcpy.html http://www.courtesan.com/todd/papers/strlcpy.html for more info about them. It's sad to see them only supported by *BSD and OS X.
- holisd 14y agostrlcpy is flawed. And often times silent truncation is not a "best-effort", but a huge hole. This is especially so when strcpy is blindly replaced with strlcpy. For new code, strlcpy is flawed.
- to3m 14y agoUlrich Drepper? Is that you? There are valid reasons not to use strlcpy, but we need something like it. What we do not need is this _s shit, which has all the same problems (which sometimes matter, and sometimes don't) WHILE BEING MASSIVELY HARDER TO USE. And what's the advantage? Just that it returns an errno. That's fine, but what about the rest of it? Just read the instructions for it - it's crap! (I can imagine why they think they want it to work this way, because it gives you a fighting chance again non-0-terminated source strings, but it's just never going to work properly if you've only got one size argument.) Using strlcpy, by contrast, is simplicity itself. About 99% of the time when you're using strlcpy (and strlcat), you can just do your calls, passing the same size value into each one (how convenient), then check the length of the result using strlen. Is it one less than the size of the buffer? Yes? Then assume there's an overflow, and disregard the result, assuming you even care about that. This is very straightforward to do, and (unlike this _s junk) doesn't require you to go updating counts or checking maximum values or any of that error-prone nonsense. Just one check at the end, rather than a bunch of updates and stuff scattered all through your string code. strlcpy! Just say yes!
- meaty 14y agoMight as well just use Go.
- oscargrouch 14y agoYou can use go where you use python, ruby and maybe some of the things that get done on c++. But not being C friendly , and with a GC.. for the things people still use C and C++ these days.. probably even if you want to use Go, you wont be able to.. If the guys from plan9 just get the Ken Thompson C compiler from plan9 and changed that C just a little bit, taking care that a plain C header could be added to that code the same way we could do with C++ only then, it would be possible to "just use Go" (plan9 C can be used with gcc using "fplan9-extensions")
- rbanffy 14y agoLoved the direct struct assignment. Is it plan9 only?
- oscargrouch 14y agoDo you mean, using anonymous structs for struct composition? you can do something similar with "-std=c11 -fms-extensions" The only thing it will be missing from plan9 c will be the automatic casting from the composition to the base struct.. but its just to cast to the base struct when you need to reference only the parent struct, polymorphism. (Ken Thompson called this effect as "Poor man classes") Macros can be handy when you need to hide this nasty castings away when not using the plan9 extension.. the nice thing about "-std=c11 -fms-extensions" is that it works with gcc, clang and vc.