C11, yo | Hacker News Reader

C11, yo

lcinexile.blogspot.fr

37 pointsreirob49 comments

I support a lot of the language cleanup, but goddamnit can we either a.) bring pitchforks to Redmond to get proper VS support, b.) bring pitchforks to $CLANG_DEV_LOCATION to get proper Windows support for Clang thus obviating the need for a, or c.) write some shims so that C11-ish features are available in Windows.

There is a world outside of Linux and mobile.

I don't know if Microsoft will ever have enough C-only customers to actually get around to supporting C11. They do a bad enough job of supporting larger subsets of their customers (like .NET developers).

Maybe I'm misinterpreting your language but I don't see how pitchforks will help. There are simply not enough Windows users among clang/llvm developers and none of the companies that are invested in clang/llvm use it for Windows technology. If Windows users want a working C/C++ compiler they will have to stand up and actually contribute, but that seems to be a foreign concept to many of the developers coming from that platform (purely anecdotal and I have no real evidence). It is not like anybody is actively trying to make clang/llvm not work under Windows.

On the other side of the fence Microsoft has repeatedly stated that they are not interested in supporting more of ISO C than they already do and want to focus on C++ (even going so far as to recommend the C++ compiler for developing C code). And apparently that "focus" on C++ hasn't even helped them overtake or even get even with their free (beer and freedom both) alternatives. That goes a long way to show in what state their compiler division is and so I wouldn't even bet on getting anything halfway decent should they commit to C11. That is not to say that there are highly competent people on that team, but there is simply to much to do and too many old mistakes to rectify first.

>they are not interested in supporting more of ISO C

>* For C++11 conformance, we're interested in implementing the C99 Standard Library

Source: https://connect.microsoft.com/VisualStudio/feedback/details/...

According to Herb Sutter only the parts that are a subset of the C++ standard: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and...

Nothing is more infuriating than half-baked support that makes you run around with feature tables and obscure seemingly arbitrary coding guidelines ("use only this subset of this feature", "if you use this thing, remember to have a workaround for VS").

I assume that part of the cruft is having to support Windows ABI, etc. Is there a straightforward way to add that to Clang/LLVM? Then MS could stop working on C compilers and instead continue improving their already-amazing IDE tools.

Anyone here able to comment on what difficulties the VS team faces?

c) sort of exists in the form of https://github.com/libav/c99-to-c89, although currently it only supports the subset of c99 that FFmpeg uses.

There is indeed a world outside of Linux and mobile, and most of that world doesn't have a problem working with C99 and C11. Windows is - as with many other things - the exception, and it's getting tiresome.

There's no way Windows developers are going to stop using Visual Studio - and rightly so, because it's a very good IDE. So there are basically three things Microsoft could do to resolve this situation and let Windows developers make use of modern C code:

1. Update their C89 compiler to a newer C standard. This is unlikely, and probably a lot of work for Microsoft (I'm guessing they'll be removing the C compiler from one of the next releases of Visual Studio).

2. Add support for essential C99/C11 features to their C++ compiler, such as designated initializers. This would still force us to compile our C as C++ and do nasty things like casting the return type of malloc, but it might be the easiest solution.

3. Switch to a modern, open source C compiler like Clang. I would be very surprised if Microsoft would do anything like this (else IE would be using WebKit already).

So we're basically forced to either butcher our C code to make it compile as C++, or write C89. Or drop MSVC support, making our projects difficult for Windows developers to work with.

Or choose the path of least resistance and use C++. Even if it is C-like C++. Not that I wouldn't like to have MS to support C99 and C11 though.

That may work for developers writing their own projects on Windows, but presents a problem when using other people's code.

Not many developers on Linux and OSX are going to hold out on using new features just to coddle Windows users.

So Linux does not have C++ those day? (Just kidding.) But C++ definitely matches C feature for feature, even tough the way or doing things are not always the same.

And what about QNX, Aix, HP-UX, Solaris, VxWorks and many others?

Not everyone is allowed to use modern versions of clang and gcc.

That was exactly the case at my last job. We used only a small subset of C99, primarily stdint.h.

From a technical perspective, though, the latest standards are easily usable on AIX. IBM has done a good job of keeping XLC up-to-date, and it has supported C11 since May.[1]

[1] http://www.ibm.com/developerworks/rational/library/support-i...

I think the most problematic is HP-UX and all the non UNIX based systems, specially the ones where the vendor's compiler is the one to use.

Another option is the Intel C(++) compiler, integrated directly into Visual Studio.

As someone who just started playing around with C++ after many many many years of absence, i must say i am surprised how well it goes. I love the new "auto" keyword for variable declarations. I had a hard time to get into pointer arithmetics again but it's slowly coming back.

Also i took this opportunity to use LLVM/clang, Qt5, Qt Creator and all in all i'm really surprised. I thought everything would be much more cumbersome, i'd have to dig through terrible error messages or reinvent basic stuff on my own, but so far the stdlib and Qt offer what i need.

If you're like me amd avoided C/C++ like the plague, i'd suggest you try again next time, it may not be as bad as you remember :P

Just FYI: this article is about C11, not C++11. It was easier in the past when their revisions came in different years ;-)

I know, but it's slightly related :P

"Variable-length arrays, alone, would save a tremendous amount of time and energy"

That is, until you overflow the stack with no way to know if that's going to happen and no way to recover if it does.

Firstly, that can happen with fixed-length arrays or even without arrays, too.

Secondly, I don't have access to the official standard, but it would surprise me if it required VLA's to be stack allocated. That would give implementers of the language too little leeway.

In fact, I see no clear reason why the standard would mention the word 'stack' at all. A quick check of the candidate PDF of the standard seems to confirm that, but that's not the real standard, and it may be a shortcoming of the iOS PDF reader.

I don't really see how variable length arrays save time? Those seem like a feature that belongs in C++ but definitely not in C imho.

However, what I like to see in C are "//" style comments, declaring variables at other places than start of scope, the integer types with bit size specified, etc...

But the VLA's? They're created on the stack, right? So you'd need malloc for large ones anyway.

What actually would save time (for the coder of course) in C, imho, would be a way to automatically clean up resources no matter where you exit a scope or function. Something like destructors do in C++. E.g. if you could type something like "onleave free(myresource);" which would execute what you type after "onleave" whenever the scope exits.

    However, what I like to see in C are "//" style comments, declaring variables at other places than start of scope, the integer types with bit size specified, etc...

All of those are already in C99...

And malloc() takes more time than subtracting a variable from the stack pointer. Though VLAs have pitfalls so you probably don't want to use them outside of throw-away code anyway.

> However, what I like to see in C are "//" style comments, declaring variables at other places than start of scope

Good news, those are both part of C99 (http://en.wikipedia.org/wiki/C99), which is supported by both GCC and Clang.

Regarding your 'onleave' idea; go has a similar construct called defer [1], it is exactly what you are talking about and (imo) is a really elegant way of dealing with cleanup.

[1]http://golang.org/doc/effective_go.html#defer

I love $new_C_stuff, but variable-length arrays are generally a security hole waiting to happen. Be very careful before using them.

What do you mean by that? All I can think of is taking user-supplied input as the length of the VLA, but I would hope anyone using VLAs are not stupid enough to think that giving the user control over the size of their stack frame is a good idea.

I'd say that most of the time when you want an array whose size is variable, the size relates in some way to user input. Your mileage may vary.

"All the major C compilers have committed to implementing these features": including MSVC, which doesn't even implement C99?

"Static compile-time assertions allow the use of sizeof() and friends" could already be done with the preprocessor and typedefs; see e.g. C_ASSERT: http://msdn.microsoft.com/en-us/library/windows/desktop/ms67... It will still be nice to have a standard way to do it, though.

Technically, Microsoft doesn't tout their C++ compiler as a C compiler, just a C++ compiler that has support for certain older C features.

There are very few C compilers that implement the whole of C99.

If you don't support the standard you don't have a C compiler; MSVC is a lot of things but a C compiler is not one of them.

According to Herb Sutter on Visual C++ (assuming this is still the official stance):

"We do not plan to support ISO C features that are not part of either C90 or ISO C++."

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and...

Microsoft doesn't consider themselves a C compiler vendor. They only ship a C compiler because they shipped a C compiler.

Really, I think we'd be better off if they actually removed it from future toolkit releases. That way no one would be confused into thinking that Microsoft supported C.

Unfortunately, Variable Length Arrays (VLA's) are optional in C11. So use of VLA's may lead to portability problems, especially if you care about your code getting compiled on minority compilers.... such as MSVC.

For this reason I'm not planning on allowing the use of C11 features in e2fsprogs, because I know there are people compiling libext2 so they can access ext[234] filesystems using FUSE on Windows (and MacOS, but MacOS is at least using a reasonable compiler).

Why are C11's char16_t and char32_t simply typedefs for uint16_t and uint32_t instead of new distinct types? C++ needed a distinct char16_t type so functions could be overloaded for both char16_t and uint16_t. I guess the C standards committee wants to ease char16_t adoption for code that is already using uint16_t for UTF-16.

Variable length arrays:

If, because of parameters outside the programmer's control, a call to malloc() fails to allocate an array of n doubles, it returns NULL.

If, because of parameters outside the programmer's control, the variable-length definition “array double arr[n];” fails to allocate an array of n doubles, the behavior is undefined.

Your choice.

See http://stackoverflow.com/a/12412774/48015 for the rationale behind the introduction of VLAs.

How do you "allocate" memory on stack? You can always do 'double arr[huge_constant]' and, depending on resources, overflow heap data. Or with recursion. Damn those bugs >:-)

The thing about C is that programmer should do check size before calling function with double arr[n]. Isn't that point of C? On the other hand, user can make fast stack allocation which, depending on situation, can be good. Stack is insecure by default, OS should put it really far from other parts. In embedded systems, well there you must always think about these kind of things.

Btw, how are (p)thread stacks implemented? Every thread has it's own stack, that's ein interesting situation.

> How do you "allocate" memory on stack?

I have no idea why you would be asking me this, unless you are quibbling over the idiom associating the verb “allocate” and the complement “on the stack”, in which case Google should be able to find you about 56000 uses, in context, of this precise association.

> The thing about C is that programmer should > do check size before calling function with double arr[n]. > Isn't that point of C?

What part of “because of parameters outside the programmer's control” do you not understand? What limit, in a portable C program, do you check the value of n against before allocating a VLA of size n?

No computed goto's :-/

>which drives coders away from C, which harms (a different type of) portability.

I'd say writing as much code as possible in other languages (whether guile or perl/python/ruby/java/...) improves portability. C code tends to be less portable than that written in higher level languages.

I disagree. C compilers are everywhere. A C compiler is the standard tool expected (and provided) with every embedded processor I've ever worked with. As a rule of thumb, if a microprocessor is meant to be user-programmable, you get a C compiler with it. It will be a long time before I get a Ruby interpreter for a blackfin processor.

You get a C compiler sure, but will a given C program work on it?

Maybe not for ruby, but I'd certainly expect most new processors to run Java. A quick search suggests there are ruby interpreters for blackfin - and if you have a ruby interpreter you can be reasonably confident any given ruby program will behave correctly on it.

There is a bare-metal ruby cross-compiler?

Or are you talking about the ruby interpreter written in C running on an OS written in C?

Java is available? Again are we talking about a bare-metal Java compiler (possibly supported by hardware being able to execute a subset of Java natively), or the large collection of software written in C and C++ that is supplied by Oracle?

Ruby interpreter written in C running on an OS written in C.

No this is not inconsistent; I said move as much code as possible away from C. That which is impossible to move has to stay in C (and will probably be responsible for 99% of the headaches when porting to a new architecture).

"A quick search suggests there are ruby interpreters for blackfin"

I disagree. A google search for blackfin ruby interpreter did not suggest that to me.

Good luck getting a JVM working reasonably well on a low-horsepower CPU. C is always your best bet for something usable.

Depends on what you consider a low-horsepower CPU, many developers still use Assembly for many of them.

Hmm, good point. I think these days I'd consider "low-horsepower CPU" to top out around a 400MHz ARMv5, maybe? Eh, it's pretty arbitrary, I suppose.

Reply on news.ycombinator.com