Live data from Hacker News

ISO C is increasingly moronic

varnish-cache.org

51–60 of 175 posts

Re: ISO C is increasingly moronic

#51

Earlier quoted context omitted.

I don't agree with your assertion that backwards compatibility isn't important, but I would like to point out that the very fact that C compilers allow you to use identifiers that are in the form _Word means that they are breaking backwards compatibility by introducing new keywords. Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.

Initial underscore followed by a capital letter is a reserved "namespace" since 1990, as a previous commenter noted. (And for the record, identifiers that begin with two underscores are reserved for use by the implementation, and identifiers followed by a lowercase letter are guaranteed to be unreserved as long as they are file-scoped symbols, and not globally visible.)

Yes, I realize this, but since it's only "reserved" in the specification and the compiler doesn't enforce this, there is a massive amount of code that does this today.

The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code.

Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee.

Re: ISO C is increasingly moronic

#52
post #10

Nothing good ever came from a committee.

The constitutional convention of 1787 seems to have done a pretty decent job.

Minus the 3/5ths compromise of course...

http://en.wikipedia.org/wiki/Three-Fifths_Compromise

Committees are all about compromise and compromises are usually a worse solution in everyone's eyes. I'm not saying C14 threads are as bad as slavery, but they are a compromise that I'm sure no one will prefer to their native thread library.

I'm a bit surprise that ISO is even attempting to do generic threads. Who is this really a problem for? We have oodles of libraries that provide cross platform thread libraries. I don't see why we need the C standard to specify one.

Re: ISO C is increasingly moronic

#53
post #49
post #17

Earlier quoted context omitted.

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and ve…

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password.

It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.

Re: ISO C is increasingly moronic

#54
post #47
post #41

Earlier quoted context omitted.

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses .

Think about C++: not only legacy C++ was broken by each standard, it was also broken by each compiler releases. The change of compiler release was always a journey. It is normal that introduction of a new keyword breaks legacy C. A new standard is compatible with legacy code if the only adaptation required is to rename identifiers that collides with new keywords. There is no excuse for producing such a crap.

C++ also goes out of its way to avoid introducing new keywords for exactly the same reasons as C.

Re: ISO C is increasingly moronic

#55
post #34

Earlier quoted context omitted.

You mean the job where the first 10 ammendments were necessary after just two years ? :-)

Amendments 1–10 and 27 were products of the same Philadelphia Convention that produced the US Constitution, and were proposed along with it. You could try Wikipedia: http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Ph...

Nothing you said negates his argument. Why didn't the committee ad them to the constitution itself when it was passed?

Re: ISO C is increasingly moronic

#56
The Sydney Opera House is a good example, actually.

It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently).

There's just one problem. It's not a very good opera house. The structural requirements make it impossible to have an ochestral pit for the musicians, and the shape of the building make it very difficult to have all the usual invisible magic that makes opera work smoothly. It's cramped and oddly shaped.

The SOH is a perfect example of the triumph of style over substance. The New South Welsh who commissioned it are now facing a $1 billion dollar bill for maintenance over the coming decade.

edit: decade, not 5 years.

Re: ISO C is increasingly moronic

#57
Well this sounds very messy, the fact you can't change the stack of the thread is a no go for many purposes, just an example, in Redis this must be done because otherwise lzw encryption will cause a stack overflow.

Also the ISO C guys completely miss how important is to provide a better libc with data structures and so forth, very very very well designed.

About the epic quote of C being a language without ambitions, one of the reasons if D or Go, or other languages are going to hardly replace C is that they are indeed, too ambitious. No one is trying to fixing C with minimal but important changes.

Re: ISO C is increasingly moronic

#58
The C standards committee has been broken since C99 introduced long long, thus silently breaking conforming code.

How do you print out a size_t, portably, without losing information? The standard says size_t is an unsigned integer type, but doesn't say way size. However, the C89 spec explicitly stated that there are no integers sizes longer than long- so the conforming way to do this is to explicitly cast the size_t to unsigned long (which, while it may add bits, is guaranteed not to lose them), and print the unsigned long.

In an attempt to save all the broken, non-conforming code that assumed that sizeof(int) == sizeof(long), C99 introduced the long long type. And, among other things, allowed size_t to now be unsigned long long. Which meant the conforming C89 code that wants to print out a size_t is now wrong. Worse yet, it's silently broken- because the type cast is explicit, the compiler has to assume it's correct. They added a new way to print size_t's, granted- but this is no help for the legacy code (or code that needs to continue to support C89-only compilers).

Of course, the punchline here is that I have yet to see code that assumed sizeof(int) == sizeof(long) that didn't also assume sizeof(void *) == sizeof(int). So all that broken non-conforming code they were trying to save? It still needed to get fixed for 64-bit.

Re: ISO C is increasingly moronic

#59
post #10

Nothing good ever came from a committee.

Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

Re: ISO C is increasingly moronic

#60
post #53
post #49

Earlier quoted context omitted.

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.

First off, I didn't realize. I'm sorry.

     I am responsible for so much old code that 
     I say we should not cripple the future for it.
I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.
Post reply on HN