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

The Descent to C (2013)

chiark.greenend.org.uk

Post reply on HN
Print view View original

41–50 of 96 posts

Re: The Descent to C (2013)

#41

Post by junon »

aidenn0 wrote: post #38
junon wrote: post #37

Earlier quoted context omitted.

To be clear, signed integer overflow is undefined. Unsigned integer overflow is well defined. This is why some C programmers dictate that all code must use signed integers to avoid unexpected bugs, but many others (including myself) disagree that's a good way of going about it since, as you said, it's not guaranteed to trap or do anything to help the programmer.

I've never seen signed-integers being required. They tend to introduce unexpected bugs rather than prevent it. Of course you can accidentally end up with signed integers when you didn't intend it. Here's my favorite accidental undefined signed integer overflow, assuming 32-bit integer size (the 64-bit version is similar) uint32_t foo(uint8_t x) { return x Yes, this is signed integer overflow, since x gets upgraded to…

If memory serves, the LLVM Project prescribes signed integers be used in all cases except where unsigned is mandatory.

Re: The Descent to C (2013)

#42

Post by [deleted] »

LeifCarrotson wrote: post #15
bachmeier wrote: post #10

Earlier quoted context omitted.

> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.

Most programmers probably weren't aware of this, but no true Scottish C programmer would be unaware of it. If you want to manipulate memory directly - which is risky though sometimes useful - C is one of the best languages in which to do it. Memory addresses are numbers, and C will let you work with those numbers in whatever way you want: add, subtract, multiply, divide... and if you didn't shudder at the suggestion…

[deleted]

Re: The Descent to C (2013)

#43

Post by DannyB2 »

The following is NOT a criticism of C. Just pointing out different problem domains.

> Modern high-level languages generally try to arrange that you don't need to think

> or even know – about how the memory in a computer is actually organised

Modern high-level languages try to arrange that you don't need to focus on the irrelevant. If you're working on, say, an accounting system, memory layout is not part of the problem you are trying to solve.

For certain applications, C is simply too low level.

A language is too low level when it forces you to focus on the irrelevant.

For low level operations you probably cannot beat C.

Re: The Descent to C (2013)

#45

Post by kaba0 »

DannyB2 wrote: post #43

The following is NOT a criticism of C. Just pointing out different problem domains. > Modern high-level languages generally try to arrange that you don't need to think > or even know – about how the memory in a computer is actually organised Modern high-level languages try to arrange that you don't need to focus on the irrelevant. If you're working on, say, an accounting system, memory layout is not part of the probl…

As per the somewhat famous blog post: C is not a low-level language. Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It has no real way of managing cache, has absolutely zero support for vector instructions, etc. *

With these in mind, Rust is lower and higher level than C at the same time.

* other than some compiler specific pragmas, but I would be hesitant to call that natively supported

Re: The Descent to C (2013)

#46

Post by kaba0 »

tialaramex wrote: post #26
PEJOE wrote: post #9

Earlier quoted context omitted.

That you can do functional or OOP in C does not make C either kind of language, it just means that C is flexible enough that you can make the computer do things the way you want it to, no matter what that means, and other languages purposefully prevent you from doing what you might want to do. C++ is object oriented not because it has compile time support for polymorphism or any of that other bad programming practice…

Hmm. In what sense do you believe that class has a code section that "lives" on the stack or heap? On a modern system you can't usually do that because of W^X rules (also on a non-x86 modern system the performance would be abysmal if you tried because why waste transistors supporting something only crazy people would want?) So perhaps notionally in the abstract machine if I have sixteen Clowns in a C++ vector there a…

Regardinf W^X, doesn’t the Linux kernel has some optional expensive debug operation that can be turned on/off through a self-modifying code removing the expensive branching?

Re: The Descent to C (2013)

#47

Post by munificent »

kaba0 wrote: post #45
DannyB2 wrote: post #43

The following is NOT a criticism of C. Just pointing out different problem domains. > Modern high-level languages generally try to arrange that you don't need to think > or even know – about how the memory in a computer is actually organised Modern high-level languages try to arrange that you don't need to focus on the irrelevant. If you're working on, say, an accounting system, memory layout is not part of the probl…

As per the somewhat famous blog post: C is not a low-level language. Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It has no real way of managing cache, has absolutely zero support for vector instructions, etc. * With these in mind, Rust is lower and higher level than C at the same time. * other than some compiler specific pragmas, but I would be hesitant to call…

> Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level.

It's effectively the lowest you can go without throwing portability out the window. It doesn't let you manage caches directly, but it gives you good control over memory layout in general, and that's often enough to give you good cache usage across a variety of chips.

If you want to go lower than that, you're probably looking for assembly.

Re: The Descent to C (2013)

#48

Post by AceJohnny2 »

> So why is C like this, anyway?

Worth mentioning that C is over 40 years old, and was designed to be easily portable across a range of machines that had less compute power and memory than today's smaller microcontrollers.

As a result, a lot of things were left undefined, or were designed in a way to be easy to implement rather than easy to program for.

There existed other programming languages that were better, but their compilers weren't as broadly available, and their better features came at the cost of speed, which at the time was a premium.

Re: The Descent to C (2013)

#49

Post by fsckboy »

AceJohnny2 wrote: post #48

> So why is C like this, anyway? Worth mentioning that C is over 40 years old, and was designed to be easily portable across a range of machines that had less compute power and memory than today's smaller microcontrollers. As a result, a lot of things were left undefined, or were designed in a way to be easy to implement rather than easy to program for . There existed other programming languages that were better, but…

> left undefined, or were designed in a way to be easy to implement rather than easy to program for.

I'd tweak your statement a little, or even a lot: "left undefined" most often meant "left to be defined by the compiler writers to fit the architecture of the underlying hardware, in a way that would make it easy to program to beneficially exploit features of the architecture"; and (yes) in a way "that would not be very portable, and might even be subject to change between compilers".

did the underlying machine use 2's complement? did the underlying machine have addressable bytes? big endian? 8, 16, 32 or 36 bits?

These are all things you need to know to write tight efficient code in the days of slow clockspeeds and limited RAM. C let you do that without using assembly, but by using the "undefined" features of the language, because they were clearly defined locally and were features that were very important to be easy to write code for.

consider how you would implement setjump and longjump, or even printf, or efficiently unpack or serialize bits for a communications protocol, without these supposedly "undefined features", or how you would write those if those features were actually undefined. People who put strlen(str) or a divide and a mod in the control expression for a loop would know better if they understood a bit more about the undefined features.

this is in contrast btw with some other things that actually are undefined, such as what the order of evaluation would be for complex expressions making up argument lists, etc.

I'm writing this explanation not so much to explain these technical details to noobs, but rather to get the people who understand this stuff to stop throwing around the term "undefined" with regard to C because they are cooperating in the evisceration of some ideas that are really worth exploring or understanding more deeply.

Re: The Descent to C (2013)

#50

Post by jart »

junon wrote: post #36
bachmeier wrote: post #10

Earlier quoted context omitted.

> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.

Eh? Says who? Every C programmer I've ever met knows about this. It's basic C.

Yeah you have to do something like this if you want to truly raise eyebrows.

    /\
    */ best c comment
    *\
    /
Post reply on HN