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

Pointers Are More Abstract Than You Might Expect in C

stefansf.de

Post reply on HN
Print view View original

151–160 of 267 posts

Re: Pointers Are More Abstract Than You Might Expect in C

#151

Post by mcguire »

MaxBarraclough wrote: post #75
gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

> I think there's room for other languages to occupy a similar space but they're need to focus on no-std-lib no-runtime operation (not always the sexiest target). You're describing the Zig language! It aims to be as fast as C, and unlike most languages that say this is a goal, it means it. There's no "almost as fast as C if you ignore the garbage-collector and the array-bounds-checking", it's actually as fast as C. I…

Does Zig have a memory management story other than C's? Anything like Rust's borrow checker?

Re: Pointers Are More Abstract Than You Might Expect in C

#152

Post by kbp »

jcelerier wrote: post #108
kbp wrote: post #70

Earlier quoted context omitted.

> I always thought [] was just syntactic sugar over a regular pointer, but seems like I was wrong. For another example showing their differences, if a.c has: int n[] = { 1 }; And b.c has: extern int *n; printf("%d\n", *n); Then running b.c will segfault, whereas if it said extern int n[], it would work as expected (hint: extern int n and printf("%d\n", n) would also work). Arrays degrade to pointers at the drop of a…

> Then running b.c will segfault why would it not ? On one side you declare an int array of size 1, on the other side you declare a pointer. Think about what's going on with the bytes : int n[] = { 1 }; will look exactly the same in memory than int n = 1; which is of course not compatible with int* n = 1; Arrays by themselves have no indirection in C. => https://godbolt.org/g/xwT7uW

Right, that's what I was explaining. A lot of people get tripped up by this because arr is equivalent to &arr, int arr[] is equivalent to int *arr as a formal parameter, etc, so many people go around with the idea that arrays are just pointers in C, like in the comment I quoted; it's an easy thing to get confused by. I was giving an example to demonstrate how they differ.

Re: Pointers Are More Abstract Than You Might Expect in C

#153

Post by pjmlp »

hexane360 wrote: post #130
bitwize wrote: post #89

Earlier quoted context omitted.

> A pointer is just an integer and I can manipulate it like an integer. Except it's not. Not unless you cast it to uintptr_t. Doy. :) Understanding the underlying asm can give you context for what a pointer is, but you can't assume that a pointer is an integer, any more than you can assume 'int' is a machine word in length. There are reasons why C seems so abstruse and abstract. It has to exist on a huge variety of a…

The obvious flipside of this is that those C programs written for Burroughs never had any chance of running on anything but Burroughs. The only difference is that C offloads the effort of portability onto the user, whereas other languages at least attempt to make it portable in the compiler.

What?! Since when did Burroughs had a C compiler?

NEWP was and is more than enough, while being much safer.

Re: Pointers Are More Abstract Than You Might Expect in C

#154

Post by xenadu02 »

mpweiher wrote: post #3
gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

> the compiler needs to optimise ... wants to. There fixed that for you ;-) The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Which is why the Linux kernel, among others, has to set…

> The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs.

Citation needed.

Signed overflow being undefined behavior was a direct consequence of different hardware representations of numbers. Inserting the instructions required to catch overflow and make it wrapping would be expensive, at least on some systems.

The fact that arrays decay to pointers, C has no dynamic array support, and so on are decisions that go way back and more or less prohibit array bounds checking. After preprocessing, inlining, and various forms of optimization it can be very far from obvious that some random NULL check after the pointer has already been dereferenced is intentional and shouldn't be removed.

Things like overlapping pointers have always had undefined behavior in the sense that inserting the instructions to check for the overlap all over the place would have a large performance impact, no one would use such a compiler, and thus there is no market for one. The standards committee largely documented existing practices rather than inventing new undefined behaviors.

I keep seeing people like you claim we should just "fix" undefined behavior or the standards committee gleefully inserted undefined behaviors because they hate programmers. If you actually sat down and disassembled the C code you write then went through the exercise of inserting instructions to eliminate most types of undefined behavior I suspect it would be a very illuminating experience. I also doubt you'd be so certain of your position.

Re: Pointers Are More Abstract Than You Might Expect in C

#155

Post by pjmlp »

CyberDildonics wrote: post #85
gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

I feel like C++11 and Rust have shown a way forward and the C standard should focus on a design that takes into account ownership and protected arrays in a simple way, hopefully as backwards compatible as possible. Maybe the solution is for the major compilers to default to strong static analysis. Even though there are safe languages, the enormous integration and compatibility of C means that it isn't going anywhere…

It is a matter of mindset, multiple safe C variants have been attempted throughout the years.

Even lint was already available in 1979, yet hardly anyone used static analysis tools on C codebases.

Re: Pointers Are More Abstract Than You Might Expect in C

#156

Post by saagarjha »

hexane360 wrote: post #130
bitwize wrote: post #89

Earlier quoted context omitted.

> A pointer is just an integer and I can manipulate it like an integer. Except it's not. Not unless you cast it to uintptr_t. Doy. :) Understanding the underlying asm can give you context for what a pointer is, but you can't assume that a pointer is an integer, any more than you can assume 'int' is a machine word in length. There are reasons why C seems so abstruse and abstract. It has to exist on a huge variety of a…

The obvious flipside of this is that those C programs written for Burroughs never had any chance of running on anything but Burroughs. The only difference is that C offloads the effort of portability onto the user, whereas other languages at least attempt to make it portable in the compiler.

Why not? As long as your program is standards-compliant, it should work on any computer with a working C compiler…

Re: Pointers Are More Abstract Than You Might Expect in C

#157

Post by steveklabnik »

Scarbutt wrote: post #138
steveklabnik wrote: post #128

Earlier quoted context omitted.

While many people use nightly, the statistics show that most use stable, with some using nightly in addition. You just hear about nightly more.

Is that still true for libraries? I think that's what he meant, not all rust users as a whole. My impression certainly agrees with him.

If a library uses nightly, then you have to use nightly to use it.

At this point, the only major library that requires nightly is Rocket, and Actix-web has been rapidly ascendant due to (rumordly) being used in production by Microsoft, and working on stable.

The data, from last year’s survey, (which means even more stuff was nightly only, for example, the RLS) where you can choose multiple options https://blog.rust-lang.org/images/2017-09-05-Rust-2017-Surve...

Re: Pointers Are More Abstract Than You Might Expect in C

#158

Post by saagarjha »

Sharlin wrote: post #133

> ...or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space. I was not aware of this special case. What's the rationale? Is there even a way in standard C to guarantee that two array objects are laid out in memory like that, with no padding?

A two-dimensional array?

Re: Pointers Are More Abstract Than You Might Expect in C

#159

Post by steveklabnik »

jeremiep wrote: post #143
pests wrote: post #119

Earlier quoted context omitted.

I don't believe it is possible to hand tune every program to beat a compiler.

When you realize the compiler's optimizations only account for about 10% of the total program's performance you find that the other 90% is entirely up to the programmer. Architecture, data structures, batching operations, memory locality, and a bunch of other metrics are all concepts the compiler can't really help you with whatsoever and they have a much larger impact on performance than the 10% the compiler is actua…

Where do you get that 90/10 split from? Just curious.

Re: Pointers Are More Abstract Than You Might Expect in C

#160

Post by saagarjha »

armitron wrote: post #87
_RPM wrote: post #74

if you're adding 1 to a pointer, why would you expect it to be equal? I would not expect it to be equal.

He's adding "1" to the pointer that points to the variable "b" which in this case is allocated immediately below "a" in the stack. Thus adding one will make the two pointers equal.

The layout of things on the stack is completely implementation-defined.
Post reply on HN