How many people code in C these days, and if so, why?

[olkipukki]

Nobody mentioned JavaScript yet? 

GUI in C#? Come on, grown up kids do everything in Electron and React Native these days 

[intmpe]

There is a huge difference between a commercial R&D facility, even ones as freewheeling as Bell Labs or PARC, and academia. The ongoing development of C & UNIX had to be justified at some point by a commercial aim, specifically the pretext used was to to produce a text processing system for the Bell Labs patent processing office. They might be ideas factories, but they are ideas factories that are expected to produce something that works at the end of the day driven by very different forces than academe.

There is actually not. Universities are businesses. They say at business school that engineers make the worst business people. This response proves it.

Well, the first business that I was one of the 3 on the senior management team in the 90s went from zero to a profitable turnover of £6 million in its first year, so yeah, engineers clearly make terrible business people - I'm living proof!

Before you launch off making sweeping and somewhat ad homiem remarks on here, it's wise to consider that there's a lot of folks on here who've been around the block more than once or twice. What next, telling Win that he knows nothing about writing textbooks? Also, using "business school" as support for an argument is likely to draw hollow laughs out of anyone here who has encountered the output of "business schools" in real life. Hint: Most of them need assistance tying their own shoelaces.

Moreover, the idea that Universities are (or ought to be) businesses is more telling of a certain mindset than it is an accurate description of Universities. They are supposed to be institutes of learning and research.

Basic, Pascal, Minix, Linux, GNU, Netscape all came out of non-commercial activities. Even the Win3.1 TCP/IP stack that got everyone on the internet was non commercial.

If one were to be more correct then its the old addage necessity is the mother of invention. Managers and hence companies are by their nature non innovative and non-creative. If you want to find the most non-creative person in a company - go to the c-suite. When I was in GE research labs we had one of the luminaries come back in. He effectively lectured the managers that while they may want something NEVER pre-define the research outcome because if you do you will get nothing. And so it was. Good researchers will deliver output - I have never not delivered - but its not always what they want. What they want is not always possible. i.e. cost.

I'm not the one that contends that academe has not produced a good programming language.

Well, don't make dumb shit remarks about R&D vis a vis Universities if you've never been in a both a real industrial research campus doing hardcore research and a University - because if you were around in 90's like I was then you know what you said was garbage. You aren't the only one who has been around the block. I'd go toe to toe with any of the wannabees I've seen on here so far. Looks like a hobbyist playground.

BTW UKP 6M is piss money. 2 years ago I stood one up for UKP12M and it failed because the grand poo bah couldn't get his head out of his arse. Unless you are the one pulling the strings - being in the c-suite means you are probably just someone they know wont stuff up their end. But usually in every show I've been in - its been a one man show - and sunk by one man. Making it requires sustained success over a long period of time in order to extract profits - and a hundred other success factors play into it to make sure you don't go under 2 years later. There are few who can do it and any of the ones that I know who have done it aren't really true electronic businesses in the old sense - there is some other key factor. If it happened in the 90's they probably buried it long ago. Meanwhile the local McDonanlds franchise has pulled in 20 or 30MUKP in the meantime.

I actually agree with you about business school but they do get a few things right. Generally they are useless as they all want their theories taken seriously in isolation of the real world. However this doesn't mean the long term studies of certain business environments does not have some merit. Druker for example hated electronics - thought it was over hyped and basically said more people made fortunes running laundromats than ever made it in electronics. By made it - it means standing up a company and then being able to lift it to a stable place where eventually you either continue running it or you exit with a boot full of cash i.e. the local McDonald franchisee. Druker's observation of electronics was - he said they startup and in a year or two they are gone. Being able to do that is not successful management - that's called luck. Conning money out of investors i.e. the 12M UKP example above is what its mostly about - as Rivkin used to say most businesses are set up to con the investor. But then most investors are cunts who deserve to be parted with their money. Sorry- some experience talking.

Edit: Just to add to that - electronics is transient - its easy to get an idea up and funded. Well not easy but not impossible. But the market changes quickly, and for the most part businesses can't change. They flop around trying things until they wasted all the cash they had. So after years of this crap I have only come up with one conclusion - get the company up and running and when you see the rain clouds - liquidate it and take the money or if their is a willing buyer sell it - take the money and work on the new thing. Don't stick around - Ive never seen a business come back from a changing environment. Hell once you have the money buy a McDonalds franchise. Makes a lot more sense than attempting to compete with so low cost operation that starts on a dime somewhere and eats your lunch.

[IDEngineer]

Yeah, no kidding...the horse died like 10 pages ago.

The title asks two questions. My earlier post addressed the first ("How many people code in C these days?"), the answer is it has retaken first place in a popular poll.

As to the second ("Why?"), there's been some postulating and pontificating herein with a few solid reasons scattered here and there.

Most else in this thread has been the usual back-and-forth. But a few of us actually did attempt to address the original questions....

[Berni]

Nobody mentioned JavaScript yet? 

GUI in C#? Come on, grown up kids do everything in Electron and React Native these days 

I did mention JavaScript when talking about how modern JIT in things like C# can make managed code run pretty much almost as fast as C++. Where JavaScript is no exception, thanks to the popularity of browsers it got some impressively quick JIT thrown at it.

JS is not just for browsers anymore. For example the popular chat client Discord has its PC client app written in JS with a bunch of frameworks stacked on top as its usually the case for JS. Its sneakily under the hood of a lot of things. Personally im not a fan of JS and most of this web stuff, but i have to admit it is a rather powerful and performant language these days.

I do have my share of gripes with C# too, but the convenience of "it just works" in VisualStudio makes it up for me. I don't want to muck about with setting up some fancy dev enviorment for the usual quick tool apps in throw together in it. It literally takes me less than a minute to start a new project, create a GUI app with a few buttons that does something simple and turn it into a self contained exe. I can even do this even after not touching C# for >1 year because i don't need to memorize any documentation. Its a few obvious clicks to create a project and plonk down buttons and once i get to writing code the VS intelisense autocomplete holds my hand all the time, if i do need more info what a function does i just hit F1 while the cursor is on it and bam browser pops up with documentation including a code example. There are plenty of ready to go libraries to read/write most popular file formats, graphics, communicate on the network, do OS stuff...etc I'm lazy and C# in VisualStudio caters to my laziness very well.

For doing C i would either get the already setup branded Eclipse flavor for that MCU (Cause it again "just works") or use Sublime text as a editor and build it in a console.

For Python i again go the lazy "it just works" route and install JetBrains PyCharm. Again few clicks and i have a running project with a decent code editor, compile/run, debug etc...

[bd139]

[Karel]

Yeah, no kidding...the horse died like 10 pages ago.

The title asks two questions. My earlier post addressed the first ("How many people code in C these days?"), the answer is it has retaken first place in a popular poll.

As to the second ("Why?"), there's been some postulating and pontificating herein with a few solid reasons scattered here and there.

Most else in this thread has been the usual back-and-forth. But a few of us actually did attempt to address the original questions....

My impression so far for the answer to "why?" is a combination of (in random order):

- simplicity
- availability
- stability
- portability
- reliability

It just works and gets the job done without any bullshit.

[0db]

my API functions always return -1 (failure)

+1 -> true
00 -> not boolean
-1 -> false

nice trick!

[madires]

My impression so far for the answer to "why?" is a combination of (in random order):

- simplicity
- availability
- stability
- portability
- reliability

- size of executable
- speed of executable

[engrguy42]

Well, don't make dumb shit remarks about R&D vis a vis Universities if you've never been in a both a real industrial research campus doing hardcore research and a University - because if you were around in 90's like I was then you know what you said was garbage. You aren't the only one who has been around the block. I'd go toe to toe with any of the wannabees I've seen on here so far. Looks like a hobbyist playground.

Uh oh....they're going toe to toe... 

https://media.giphy.com/media/pIwSSY4FUvs0E/giphy.gif

EDIT: Hey wait a minute...how come my gif doesn't show, only a link WTF? Anyway, we REALLY need a Tim Taylor/Home Improvement automatic grunt inserter gif thingy here.

[Siwastaja]

engrguy42, you are getting a bit boring. Repeating the joke gets old.

I see you have a mental issue seeing people disagree with each other, but if you have nothing to contribute, you can also stop repeatedly trying to be "funny" which you are failing at. Let the kids adults fight discuss.

If the awkwardness is getting at you, you are free to ignore the thread.

Thank you.

[engrguy42]

engrguy42, you are getting a bit boring. Repeating the joke gets old.

I see you have a mental issue seeing people disagree with each other, but if you have nothing to contribute, you can also stop repeatedly trying to be "funny" which you are failing at. Let the kids adults fight discuss.

If the awkwardness is getting at you, you are free to ignore the thread.

Thank you.

I'm sorry you're bored. But, honestly, I couldn't care less.

[Siwastaja]

- good-enough-ness despite all the issues
- lack of anything else that demonstrably and actually works better in the real world cases where C is still used. (Wherever C is not the right tool, it has largely been replaced already, so where it remains, there usually are good reasons.)

[Nominal Animal]

Considering the various ways success/error results have been passed from the callee to the caller in C, there are some that are "standard" in the sense of so common to not surprise anyone:

• Integer return value: 0 = Success, -1 = Error, with error code in a thread-local global variable
  This is the interface used by most standard library functions, using errno for the error code.
   
• Pointer return value: non-NULL = Success, NULL = Error, with error code in a thread-local global variable
  This is also used by standard library functions, with errno for the error code.
   
• Integer return value: 0 = Success, nonzero = Error code
  This is the interface used by most POSIX thread functions (pthreads).
   
• Pointer return value: Small range of addresses reserved for errors
  This is used internally by the Linux kernel, but requires intimate knowledge of the virtual memory available to userspace processes (see ERR_PTR(), PTR_ERR(), IS_ERR(), and IS_ERR_OR_NULL() macros in the linux kernel sources for details).  A small range of addresses at the top of the virtual memory is used to make the check a simple comparison (IS_ERR_VALUE() macro).
  In POSIX C, the mmap() function returns a pointer to the mapped region, or MAP_FAILED if an error occurs.
   
• Unrelated return value, often none: Final function parameter points to an integer result status variable
  This is common in C bindings to Fortran libraries, like BLAS and LAPACK (very common linear algebra libraries still in use).
  Typically, the result status variable is 0 for success, and an error code otherwise.
   

Each of these have their upsides and their downsides.

Even the standard C library has an exception to this pattern: strtol(), strtoul(), strtoll(), strtoull(), and strtod().  See the code snippet at the end of the man strtol man page to see the correct procedure.  I personally wrap these inside a parse_type(src, base, to) function.

The first case has lead to many programmers to use (result < 0) instead of (result == -1) to determine if an error occurs, but that is wrong if the function can return valid negative values (other than -1); or, on LP64 architectures, when the return type is long, but is stored in an int, and a larger than 2³² value happens to be truncated to 32-bit negative value.  This yields a set of common bugs when porting "bad" C from ILP32 to LP64.

The second case tends to trip programmers whenever encountering functions of the fourth type, including POSIX C mmap().

The fifth case looks "odd" in C, especially if the function does not return any value.  Some interfaces allow passing NULL for the pointer to the status variable, some do not, so it tends to be a bit cumbersome.

I personally prefer the third case, because it yields the following code pattern,

Code: [Select]

    result = some_function_call(parameters);
    if (result) {
        an_error_occurred();
    }
In cases where the error reason is uninteresting, it shortens to if (some_function_call(parameters)) an_error_occurred(); which does take a bit of getting used to, but unfortunately, it also allows the risky if (result = some_function_call(parameters)) an_error_occurred() pattern, which can easily trip up humans ("shouldn't that be == instead?").

Because of the variance in error/failure condition reporting methods, many C programmers develop an emotional distrust of the return values.  (The example of comparing < 0 instead of == -1 is a typical one.  Also, I am not excluding myself here; I'm no better than anybody else in this.)  As I mentioned above, this has lead to bugs, so it is not a good thing; it is not a defensive strategy, but an emotional cause of further bugs.  Paranoia is useful only up to a limit.

In some cases, it is even better to deliberately choose an odd error/failure reporting method (one not listed above, or one differing from the rest of the API), to ensure human programmers notice it and use it correctly; docstring comments just before the function are extremely useful for this.

Technically, it does not matter.  It is true that there may be C compilers that generate incorrect code for one of the schemes, but I would throw such a buggy compiler to a bonfire, instead of letting it indoctrinate me into not trusting my tools at all.  Compiler bugs are exceedingly rare compared to human bugs; whatever error/failure method you do use really does not (should not!) matter to the compiler.  Some of them may map better to the underlying hardware architecture, but since C does not expose the ALU status flags basically all current processors and microcontrollers have, that is already kind of a moot point.  (That is, most HW could have an ABI where one of the status flags, say Carry, is used to indicate an error/failure at return time, but current C would need to use some kind of a pseudo-variable or function kludge to expose it.  Yet, it would be extremely efficient at the machine code level, if properly exposed.)

Some see this as versatility, some as a failure, of C.  For example, the standard method of reporting error/failure in Python is raising an exception; it is simple and straightforward.

Why, then, would C need that versatility, instead of having just one simple way to pass errors like Python does?

That answer, and the answer to the question posed in the initial message in this thread, is that we just have situations where that kind of versatility is useful, and sometimes necessary.

(To repeat: they are necessary when implementing language bindings to other programming languages, and vice versa; consider the Fortran example above.  I would not want to have to write those bindings in assembly; I much prefer writing them in C.)

Is this message, and my previous message, just singing praise for C?

Fuck no.  I have tons of grievances against it, and tons more against the current direction of the C standards committee, so much so that I actually prefer C99 over C11.  I haven't even bothered to read the text of C18 yet, and have not read anything about C2x thus far.  Now that Microsoft is becoming saner with respect to FOSS, there could be an improvement coming, but standards folks move slowly, so I'm not holding my breath just yet.

C is just a tool. It has its use cases, like low-level systems programming and interfacing to other programming languages, where it is a better fit than anything else we currently have; one reason being its ubiquitous availability, and the size of the existing codebase.  In my previous post in this thread, I listed the reasons why replacing C with C++ can be problematic in this niche.

Does that mean I think C++ has no use cases, then?  No, of course not.  I personally prefer using Python for user interfaces, because I find the ability of end users to modify the UI without recompiling or setting up any kind of a development environment to be worth it.  User interfaces by their very nature are event driven, and object-oriented languages are best suited for those; so, if I was writing a proprietary GUI application where UI in Python would be unacceptable, C++ would be my choice; and  then even the low-level stuff would naturally be written in C++, not C, because using C would only increase the complexity and maintenance cost.

(As far as I know, GTK+ is actually the only native C GUI toolkit currently in use.  I do like it, but considering an entire software project with paid programmers and such, C++ and Qt or FLTK is just a better, more reasonable choice.)

What about Go, Rust, Julia, et cetera?  They have all been touted as being better at what C is used for.  Leaving marketing-speak and buzzwords alone, I want to see actual low-level libraries (plural! Not just a special case chosen for its particular quirks!) implemented and performing better, done by people who know these languages better, than to try and switch myself just because of the touted potential.  History shows these "new" languages tend to be domain-specific, and quite high-level, and not at all suited for the low-level systems programming tasks I and many others use C for.

I really wonder how many of those who believe C++ does everything C does and better, are actually Windows-only developers?  After all, Microsoft no longer has a C compiler at all, only a C++ compiler that supports compiling C too, and unless you have practical experience on other platforms, that sort of thing must affect ones experience and opinions.  Nothing wrong in that perse (), but it is extrapolating assumptions from a small region to a larger whole, which rarely matches reality.

[Karel]

..., so much so that I actually prefer C99 over C11.

Can you give some examples of what you don't like about C11?

[coppice]

History shows these "new" languages tend to be domain-specific, and quite high-level, and not at all suited for the low-level systems programming tasks I and many others use C for.

History shows that all computer languages have been domain specific, and that very often the developers were completely unaware of this. You only have to look at early stuff pushing C++. It touted the generality of its OOP features, yet always showed examples in one of the few areas where is really excels.

[SiliconWizard]

..., so much so that I actually prefer C99 over C11.

Can you give some examples of what you don't like about C11?

Also curious.

[SiliconWizard]

With respect to the use of booleans in C....

I'm a huge proponent of the style "if (boolean)" or "if (!boolean)" for several reasons. First, IMHO it's concise and clearly conveys what is being evaluated. YMMV.

Second, long ago I was analyzing the Assembly language output from a compiler and found that it generated different code depending upon how if statements were written. If I wrote "if (variable)" or "if (!variable)", it generated ultra-tight code by clearing the Z flag, pulling the variable into a register, OR'ing the register with itself which (might) set the Z flag, and then testing the state of the Z flag. But if I wrote "if (variable == true)" the compiler actually performed a comparison with an immediate value equal to "true" (or whatever value was specified), generating signficantly more Assembly instructions for the same net result.

Having learned this, I also started testing non-boolean variables for zero with "if (!variable)" which yielded smaller, faster code as described above. This was especially nice (and low cost) when checking for null pointers.

I lived in this blissful state for a very long time. THEN... my code started failing in weird ways on some project. So I dug into the Assembly generated by THAT compiler, and to my horror discovered that it did not generate proper Assembly unless a value was specified for the comparison! That is, "if (boolean)" and "if (!boolean)" generated BROKEN CODE but "if (boolean == true)" and "if (boolean == false)" did not. The != versions also generated proper code. The compiler simply demanded two explicit values to compare. I could not believe it, but I was trapped by the authors of that compiler. Once I rewrote my code to always provide a value against which to compare, it started working perfectly.

This is a long winded way of saying that despite agreeing it looks terrible and should not be necessary, I now write "if (boolean == true)" even though strictly speaking it is not necessary. I do so because that source code will always work with every compiler I've ever encountered, whereas I know there's a team out there somewhere that wrote a compiler where that would silently (e.g. without reporting an error, nor even a warning) generate broken code without the immediate value. Supporting two values with a comparison operator between them is so fundamental to the language that we can safely presume it will always work, so for reliability I now write that way. And I urge the universe to inflict terrible harm on that compiler team every time I do so.

I have personally never run into such a compiler bug. That would look like a bug on a *very* basic C feature, and said compiler should probably have never been trusted for anything else. But I know sometimes you just don't have a choice. (One bug I do remember from an old C compiler - IIRC it was cc on some old Solaris system - was an operator precedence bug. Writing something like 'if (a == b && c == d)' would not yield the proper condition, and you had to use parentheses to make it correct: 'if ((a == b) && (c == d))'. And I did grow an habit of always putting parentheses like this, even to this day. I also find it more readable. So I can relate.)

I still want to draw people's attention to the dangers of comparing C "booleans" with a constant.

As I said already, C considers 0 to be false as a condition, and non-0 to be true.

So 'if (boolean == false)' (assuming 'false' is defined as 0) is indeed guaranteed to always be correct and equivalent to 'if (! boolean)'.

OTOH, 'if (boolean == true)' is a terrible potential mess, since a *true* condition in C  is not guaranteed to have any specific value (at least before C99), so depending on how you manipulate your "booleans", that kind of test may utterly fail. And it's not just theoretical: I've seen this done in existing C code and it introduced a major bug.

Sure if you always assign your "booleans" with constants and nothing else, that should be OK. (But still pretty clumsy IMHO.)
But if you assign some of your booleans with conditions, such as: 'boolean = a != b' (which is perfectly valid, and works in most programming languages actually), then you have a problem. Before C99, such a condition was not guaranteed to have a 0 or 1 value exclusively. And I've SEEN that not being the case with real compilers. (One low-level explanation would be that such an assignment would simply be implemented as a subtract operation in assembly.)

So, beyond the style question, I think you should be very careful with this.

[Nominal Animal]

Why I prefer C99 (per n1256.pdf) versus C11 (per n1570.pdf)?

Instead of bringing portable, widely-implemented features like getline(), the standards committee was stuffed with Microsoft stooges who instead of furthering the C programming language, furthered the schemes of Microsoft by introducing the entirely unneeded Annex K.  In other words, instead of getline(), you now have the "safe" fgets_s() instead. 

None of the wide-character internationalization support got any enhancements, either.  They are not needed, after all, because Microsoft does not actually support locales (without proprietary extensions) anyway.

(I was really hoping for getline() and getwline() to get standardized, because those two alone, taught to newbies, would remove a whole slew of typical bugs and inane limitations made by new C programmers.  As it is, almost nobody localizes their C programs anymore; the standards committee has made it clear who commands it, and what direction it will be dictated in.  A big reason is that standard code that is supposed to work even on Windows, doesn't, when the Windows' user locale uses UTF-8.  Simply put, even after stuffing the C standards committee with people on their payrolls, they couldn't tweak the standard enough so that their own limpy implementation actually follows the standard.)

The immensely useful iconv_open()/iconv()/iconv_close() interface from POSIX did not get standardized, because Microsoft didn't want to implement it.  To use it in Windows, one can install the libiconv library to get the support; basically all other desktop and server operating systems already incorporate it into their C library.  But because Microsoft doesn't, it won't get into the C standard.

Instead of standardizing the atomic operations implemented by GCC, Intel Compiler Collection, and a host of other compilers (but apparently not Microsoft Visual C++, which is after all more important and equal than anything else) – noting that they were the second generation of such ops, the first being __sync built-ins, that AFAICR were originated in ICC, not GCC –, they went with their <stdatomic.h> approach, which may or may not provide some features (it is up to the implementation; although you can check it via the __STDC_NO_ATOMICS__ preprocessor macro), because that is the easiest way to implement minimal atomics support for a C++ compiler.

In C11, variable-length array support became optional, because one vendor's C++ compiler has issues with those.

Instead of leveraging existing POSIX threads with decades of C use, the committee went with a new "standard thread" support <threads.h>, whose actual compiler and OS support is unknown and iffy at best.

Instead of utilizing experience with POSIX clock_gettime() facilities, they farted out an timespec_get() whose support is, well, purely a guess.  If you have ever written a benchmark or test program that uses both CLOCK_REALTIME and CLOCK_MONOTONIC clocks, you can immediately see why the timespec_get() interface really does not cut it.

Really, if we look at C11, the really good things it provided was the _Generic() selection expression and the _Thread_local storage class specifier!

Up to C99, the C standards committee had taken already implemented things with user experience finding them useful, and standardized them.
With C11, that changed. Microsoft had decided to use it for the same purpose it standardized OOXML: to eliminate the need of having to compete with actual C implementations, and to ensure their own single-architecture C++ compiler implementation would suffice.  Simply put, they threw the C standard under the bus, because they had the money, and they thought it would help their business.

Today, if one wants to write portable C code, Windows environment is right out.  Even their locale support and terminal UTF-8 input/output won't work without using Microsoft-only proprietary extensions.  You will need to use predefined compiler macros to write Windows-specific code selected via preprocessor directives at compile time, if you do anything more complicated than a "Hello, world!" program.  I'm sure Windows-only developers find this perfectly acceptable, but me, I do not want to be slaved to a single vendor.  If a tool tries to restrict the portability of my code (like ICC did and does at runtime to code running under AMD processors), that tool goes out the window.

So, for portability and functionality, POSIX C (IEEE Std 1003.1-2008) and C99 is still the best bet.  Not perfect by any means, but the best fit, for now.  C11 and C18 could have continued the path that C99 started from C89, but instead, basically twisted the C standard into furthering the goals of a single vendor.  As I understand it, C18 doesn't even add anything to C11 anymore, and is simply a collection of errata (because the day Microsoft gets something right the first time, is the day hell freezes over).

Okay, why the vitriol against Microsoft?  It's not, really; it just happens to be the vendor that did this to the C standards committee, which allowed it to happen.  If it had been Intel or Pathscale that did it (AFAIK IBM don't have their own proprietary C compiler anymore), I'd be equally disgusted with them.  I'm angry at the entity that did this to the C standard development process.  Microsoft today is, I believe, quite different as a company, but standards development stuff moves slowly, and it may be impossible to undo the damage done.  There may not be sufficient interest to even try.

There is still hope that POSIX C continues to develop, although it remains to be seen.  One can read IEEE Std 1003.1-2017 online here, and the list of C functions and interfaces is here.

Please do realize that I am looking at this as someone who really appreciates good tools, and gets immensely disgusted when someone fucks up the future of an existing tool.  I feel the same way when a physical tool manufacturer sells their brand to a low-cost manufacturer, who exploits the brand for increasing short term profits.  This can happen even during the lifetime of a product – sadly common with computer electronics, actually, except that none of the manufacturers have a particularly good reputation anymore.

I don't care if it is C, or something else; my attitude depends only on it as a tool for solving problems, or implementing other tools.  If you feel that everything you do is already dependent on Microsoft – or some other single vendor, like IBM, who now own Red Hat and have immense (and not altogether positive, in my opinion) say in the direction desktop and server Linux operating systems (i.e., those running the Linux kernel) will take in the future – then good for you; my reasons here will be irrelevant to you, and you can safely ignore them.  But, if you are someone who has been in the software business for three decades, give or take, and don't want to be dependent on a single vendor because they will eventually fuck you over, you'll understand why the direction change between C99 and C11 has reduced my expectations from the C standards committee to zero.

I guess I should apologize for the rant, but I don't wanna.  Every point above is something that I have seen bite someone else besides myself.  The locale support and getline()/getwline() facilities are a particular sore point, because even MS actually implements them in their base "C" library; but as it is, they are practically forgotten in current C software projects.  That angers me, because it leads to bugs (buffer overruns) and inefficiencies or artificial limitations, that would have been so easy to avoid otherwise.   

[SiliconWizard]

OK, I get some of your points.

Do you have actual proof MS influenced C11 in such a way? You seem very convinced of this.

As to threads, the support is optional in C11 AFAIR, and from the little I experimented with this, GCC implements it as a thin layer above PThreads actually. But I'm expecting support in other compilers to lag. A lot.

And yes, _Generic() is interesting. That's about the only thing I've ever used from C11 so far.

[chriva]

If someone has the penguin as a profile picture you just know they'll hate ms in every way possible and even blame them for stuff they didn't do. The open source world have benefited A LOT from big corps too. Start looking for google and Microsoft mentions in the codebase of many free and mature projects.

It took Microsoft two tries. Shall we start on how many small tries it took independent developers to get things straight in their stuff?

[Karel]

<cough cough> https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes#Microsoft_funding_of_SCO_controversy

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Examples

[engrguy42]

Somebody mentioned open source. And Microsoft.

I HATE open source. I HATE IT !!! As a user it's a royal freakin' PITA.

There, I said it.

There are like 600 distros of Linux out there?? Are you freakin' serious?? How is that good for users?? Trying to get support is freakin' impossible. "Oh no, that's Cinammon, not Ubuntu...can't help ya' ".

And you go to GitHub and download some open source code from some guy, and spend most of your time reverse engineering and adding comments so you can understand the un-documented code he freakin' threw together (face it, coders HATE documenting shit). And you basically end up re-writing and documenting most of it.

And then a couple years later he's gone and his code just grows weeds.

Nothing's standard. And how can you rely on some code written by unnamed people? At least when a company is behind it they try to make it reasonably uniform and supported. And if you have a question about Windows or VS or whatever there's like 326,543 resources and libraries you can use.

Nothing's perfect, but at least with MS there's some unformity for users. And someone real to put their name behind it. Of course, there's tons of stuff about MS to dislike, but at least they have ONE product and 3.73 gazillion people all over the world using it.

Although apparently some guys love to spend unending hours playing with ridiculous command-line code. Hence Linux. 

Ok, I'm outta here. My apologies. And C RULES!!! 

[bd139]

I don't disagree with a lot of that to be honest. Some of the open source code is quite frankly fucking shit or maintained by comic book guy from the simpsons. You really have to tread carefully. One reason I'm sitting here on a windows 10 desktop and probably always will be.

But at the same time the state of the .net ecosystem isn't much better. For a company that throws ~ £6m into MSFT every year, we can get fuck all support from them on their open source projects or closed stuff. I even had to shitpost on twitter and DM Scott Guthrie to get something sorted and they still haven't fucking fixed it 4 years later. And lets not forget partner support and Connect which has been a shit show for nigh on 20 years.

The only truth is here: https://www.stilldrinking.org/programming-sucks

[coppice]

Why I prefer C99 (per n1256.pdf) versus C11 (per n1570.pdf)?

Ah, 2011 was a wonderful year. It was just about the first time you could freely code to the then 12 year old C99 standard and not get a mass of complaints about limited portability. I wonder which year we will be able to code to the C11 spec.?

[bd139]

It gets worse. Don't look at the later standards. We have attributes now as well 

Standardisation by committee is a sure way to fuck a specification.