Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

171–180 of 536 posts

Re: The Development of the C Language (1993)

#171

Post by keepamovin »

I want to read this. I'm also interested in the story of how SHA-0 was developed internally in the NSA if anyone has any idea.

I'm a little surprised at folks incredulity that C is used "nowadays". To me, there will always be a place for C. If you look at:

- the bulk of the internet traffic

- the bulk of the base OS systems and libraries it is running on

I'd say 99.9% of that is written in C. Hence my surprise.

I know Linus now embraces Rust in the Kernel or whatever and I'm not disparaging that, just seems obvious that C, old as it may be, is still highly relevant. C is a graybeard. Give it a break, right? :)

Re: The Development of the C Language (1993)

#172

Post by jcranmer »

skitter wrote: post #160
lumb63 wrote: post #145

Earlier quoted context omitted.

> There is nothing predictable about C except that you’ll eventually get screwed … This has been the exact opposite of my experience. I’ve been writing C for 10 years and have yet to find a piece of code where I was surprised at what it did. That’s one thing I love about C, is it is entirely predictable. If it isn’t, my code is wrong. The language is rigorously specified. It is not hard to avoid undefined behavior. C…

I agree with your point about Python, which is why I'm glad type hints see adoption but dismayed that they're essentially fancy comments that don't enforce the actual runtime types. The thing is, I'm not convinced avoiding UB is easy. E.g. what's the behavior of the following code? int16_t a = 20000; int16_t b = a + a;

Given that all arithmetic autopromotes to int if smaller than int, there's no undefined behavior in this code if int is 32-bits (which is true on most systems).

Re: The Development of the C Language (1993)

#173

Post by flohofwoe »

kaba0 wrote: post #128
xyzzy_plugh wrote: post #124

Earlier quoted context omitted.

What are you talking about? "in-built"? Have you ever written SIMD assembly before? It's comically easy to integrate SIMD optimizations into a C program.

Through in-built assembly, or some compiler-specific annotation. None of them is vanilla C , which was my point.

Actual "standard C" (along with most of the C stdlib) is pretty much useless for writing real-world applications, any non-trivial C code base will almost certainly use at least a handful non-standard extensions (sometimes even without knowing it) and both compiler- and platform-specific conditional code paths (just try how many libraries would compile with gcc's "-pedantic" flag, I bet it's not all that many).

This pragmatism by compiler vendors to just ignore the C standard where it doesn't make much sense, and to extend the language where it helps to solve real-world problems is actually a pretty powerful argument for C.

Re: The Development of the C Language (1993)

#174

Post by marcosdumay »

kps wrote: post #92
zabzonk wrote: post #2

i had read this before, and it has been posted here multiple times, but somehow i had missed: > Thus the core C language escaped nearly unscathed from the standardization process, and the Standard emerged more as a better, careful codification than a new invention. which made me grin.

In 1993 the unintended consequences of X3J11 “undefined behavior” had not yet emerged, nor had the reality that future Standard committees would double down rather than fix it. If anyone had realized what UB would turn out to mean, it would not have been invented that way. Dennis Ritchie's 1988 comments on the `noalias` proposal match exactly: “the committee is planting timebombs that are sure to explode in people's…

I don't think it was even possible to predict what "undefined behavior" would turn out to mean, because the modern interpretation does clearly not come from the standards text.

The standard describes the old interpretation of "if you do that, you get the consequences". The fact that somebody came up with a reinterpretation that bring a completely unreasonable meaning that just happens to be compatible with the text is all up to the people reinterpreting it. Nobody preemptively disavows unreasonable interpretations when writing something.

Re: The Development of the C Language (1993)

#175

Post by chongli »

marcosdumay wrote: post #163
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

> These statements are not true in languages which support operator overloading I guess I will never understand the C and Java developers incredible fear of operator overloading. Do you have the same reaction to user-defined functions? Because they are exactly the same thing. Is it because of the bad type system that won't let you know what operator you are using?

I guess I will never understand the C and Java developers incredible fear of operator overloading.

The answer is in the sentences right before the one you quoted:

Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow.

Consider the use-cases for C: operating system kernels, hard real-time software, low-level libraries, databases, embedded software. What is a common desire among these? Predictable low-latency and high throughput.

It's much easier to achieve these features if your language does not allow "magic." Implicit allocations, RAII, exceptions, overloaded operators; these are all examples of features which allow a library-writer to inject hidden control flow into your code. This can make it very difficult to analyze why code runs slowly or with unexpected random pauses, not to mention making it much harder to step through in a debugger.

Re: The Development of the C Language (1993)

#176

Post by tacker2000 »

keepamovin wrote: post #171

I want to read this. I'm also interested in the story of how SHA-0 was developed internally in the NSA if anyone has any idea. I'm a little surprised at folks incredulity that C is used "nowadays". To me, there will always be a place for C. If you look at: - the bulk of the internet traffic - the bulk of the base OS systems and libraries it is running on I'd say 99.9% of that is written in C. Hence my surprise. I kno…

Dont forget embedded/iot/automotive etc… The use of C will even increase as every square meter of the globe is going to be littered with small connected devices.

Re: The Development of the C Language (1993)

#177

Post by markus_zhang »

babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

For me I use C because it's the de facto system programming language for botb Linux and Windows. Another reason is that C grammar is simple (but has a lot of quirks I do admit.)

Re: The Development of the C Language (1993)

#178

Post by skitter »

lumb63 wrote: post #169
skitter wrote: post #160

Earlier quoted context omitted.

I agree with your point about Python, which is why I'm glad type hints see adoption but dismayed that they're essentially fancy comments that don't enforce the actual runtime types. The thing is, I'm not convinced avoiding UB is easy. E.g. what's the behavior of the following code? int16_t a = 20000; int16_t b = a + a;

Agreed on the dismay regarding type annotations. My opinion is that potentially misleading code which gives a sense of safety when none exists is worse than dangerous code. It lowers the programmer’s guards, which can lead to more bugs. Integer overflow will result, I’m pretty sure. The largest value a signed 16 bit (so, 15 bit) can hold is 32767, IIRC. I can see where that’s unexpected for people whose brains aren’t…

Not quite what I was getting at: On an implementation with 32-bit ints, the code is valid – the values get promoted to 32 bit, added and then truncated to 16 bit. Yet on a platform with 16-bit ints (and microchips & unusual platforms is a frequently stated reason for using C), the addition overflows and result in UB.

Luckily most other languages haven't decided to copy C's implicit promotion rules & target-dependant integer sizes.

Re: The Development of the C Language (1993)

#179

Post by DragonStrength »

mytailorisrich wrote: post #15
babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

> The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction. By and large memory is a contiguous array and the C representation closely matches what is actually happening, so I am curious about which platforms you have worked on.

Only if you ignore memory layout and understand the UB on your platform. The language does not make as many guarantees as "C is simple" folks seem to think. Throw a sanitizer at any of their code, and you'll see unaligned memory accesses all over the place.

Re: The Development of the C Language (1993)

#180

Post by dzaima »

kaba0 wrote: post #128
xyzzy_plugh wrote: post #124

Earlier quoted context omitted.

What are you talking about? "in-built"? Have you ever written SIMD assembly before? It's comically easy to integrate SIMD optimizations into a C program.

Through in-built assembly, or some compiler-specific annotation. None of them is vanilla C , which was my point.

If you want truly high-performance, architecture-generic SIMD won't get you particularly far though - the utter mess of things that x86-64 does and doesn't support is an utter mess, and doing things well across fixed-width and variable-width SIMD architectures will require compromises on one of those quite often. (not at all to say that it's impossible, it's just quite full of asterisks that I personally think is too much to bother standardizing)
Post reply on HN