Comment by Findecanor | Hacker News Reader

Comment by Findecanor | Hacker News Reader

IMHO, casts from integer to pointer should have been deprecated in C (and derivative languages) a long time ago.

Not only do they encourage unsafe practices, being forbidden in most C/C++ style guides.

They can also wreak havoc with any hardware or software-hardening that puts non-address bits in pointers. For instance, ARM PAC has been in Apple's CPUs for years now and support is mandatory in ARM v8.3 and up. Intel and AMD have also had experimental extensions that use those bits, and new ones are on the way.

When an integer is cast to pointer in those schemes, the pointer can become invalid. Therefore, an integer cast to a pointer type should always result in an invalid pointer, IMHO.

Integers are sometimes used to set alignment. I'd suggest that the macros in CHERI C be added to <stdalign.h>: align_up, align_down and is_aligned. Those can be expressed in normal C without having to cast an integer to pointer, or use faster expressions depending on the platform.

How do you do embedded then? I mean you need to specify the addrese of lets say the spi interface. Usually numbers are written as integers. So we would need a syntax for pointer literals?

I don't particularly agree with the grandparent that getting rid of pointer-to-integer casts makes sense, but at least the specific question you're asking doesn't seem like a non-starter. Two options that come to mind immediately would be making a union { intptr_t; foo * } well-defined; or adding a 'p' or 'ptr' literal suffix so 0x80004000p has type void *.

Yes type punning is still possiblem, but doesnt this violate the 'spirit' of the original idea (to get rid of conversions between int and *)

Type punning in general is undefined (unless one of the types is char * or equivalent); but defining it between intptr_t and pointer types in a few restricted contexts (e.g. for const variables of static storage duration only) would be sufficient to address memory mapped registers and restrictive enough that it should be possible to define clearly.

Or language interop? At least in jni it’s normal to store a c/c++ pointer in Java as long, and then send it back to c where it has to be converted to a pointer.

TBH I feel the opposite. "Pointers" should be simple memory addresses again without any compiler magic attached, and memory load/stores should be explicit, with the same level of control as assembly. At the least this would make manual performance optimization more predictable. There are plenty of languages "above" C, no need to move C into that direction even more, but I think the unexplored area "below" C (and above assembly) is much more interesting.

The problem is that C developers want their code to work as they expect, which is reasonable, and at the same time they want their code to be as fast as possible, which is also reasonable. But in practice these two desires are often at odds. So when C compilers start exploiting more UB in order to make code faster programmers turn around and complain, and then when C turns out to be slower than Fortran due to a lack of UB-exploiting optimizations a different segment of programmers will complain. It's a difficult balancing act for compiler and language developers.

I think "restrict" is a really nice compromise in C: Your code declares that you're willing to follow additional rules, and the compiler can make additional optimizations.

The article shows a piece of code that makes that promise and then doesn't hold up its part of the agreement. I can't even follow the rest of the argument from there because it's all based on a faulty foundation.

> The article shows a piece of code that makes that promise and then doesn't hold up its part of the agreement.

Edit: disregard; I now see your other comments.

Incorrect. The article shows a piece of code that makes and fulfills that promise, and then the optimization passes break the code. If you disagree, I would be interested in hearing how/where you think the code itself is faulty.

No, I was sloppy when I read it the first time. The second snippet of code is broken, and I (incorrectly) assumed it was a valid translation from the first snippet. My bad.

The first snippet is subtle, and I'm not a language lawyer, but I can't see anything that screams "contract violation".

I'm starting to think we need a way to allow UB-based optimisations on a per-function or per-block basis, with the rest of the code being compiled with the simplest mental model. It's getting a bit hard to reason about whether your code is actually safe or not, it would be better to compile most code as if all pointers can alias, integers wrap around, accessing nullptr is allowed, etc. (subject to per-platform quirks) Then we can mark the hot functions as candidates for better optimisation. Maybe other than an attribute we could add assertions to the code, e.g. assert_no_overlap(ptr1, size1, ptr2, size2) -- assert that the range [ptr1, ptr1+size1) does not overlap [ptr2, ptr2+size2). That could then optionally be compiled into an actual runtime assertion to help catch UB at runtime.

Ultimately the C (and C++) memory model is meant to help us write fast, safe software. Developers must be able to reason about the semantics of their code. Optimising short parts of the program that can be reasonably checked by a person for not invoking UB is probably the right way and will result in fast software with fewer bugs due to programmer error.

Edit: Not sure why people are downvoting this, it's like there's some UB religion out there. Do you people want your programs to crash due to the compiler doing surprising things?

This already exists. gcc has optimization pragmas and function attributes that allow optimization to be set on a per-function level. However, they don't really work as expected, mainly because inlining exists. Example:

  int foo(void) { return 42; }
  int bar(void) { return foo() + foo(); }

If the whole file is compiled as -O0, foo and bar must be compiled as-is. If the whole file is compiled as -O2, bar will be optimized to "return 84;". But what if foo is compiled as -O0 and bar is compiled as -O2? Can bar still be optimized to "return 84;"? What about "return 42+42;"? Can it do "int x = foo(); return x+x;"? What about "int x = foo(); if (x == 42) return 84; else return x+x;"? All of these are permitted in -O2 if gcc thinks it's a good idea, but in our "mixed mode" the semantics are unclear. It might be theoretically possible to come up with a consistent definition; it might start with "functions specified as -O0 cannot be inlined or have other functions inlined into them", but there are still more things to consider, like the behavior of global memory, thread-local storage, floating-point environment, and so on (what if one or more functions is static inline or __attribute__((always_inline))?).

The real solution with current gcc is to simply compile different files ("translation units") with different optimization flags if you want. This has always been supported. Unfortunately, it comes with a potentially significant performance penalty; the whole point of LTO is to avoid this performance penalty, but this once again returns the issue of the semantics of mixing functions with different optimization levels.

> Do you people want your programs to crash due to the compiler doing surprising things?

I obviously can't speak for everyone who defends this sort of compiler behavior, but my preferred solution is for the compiler to continue performing these kinds of optimizations while also providing better static analysis and sanitizer tools to catch problems earlier, even if that involves extending or replacing the language to make that possible.

Expecting everyone who writes C or C++ to do this kind of reasoning in their head and perform these optimizations manually (or drop their performance back toward -O0) just sounds like it would make things worse.

> Ultimately the C (and C++) memory model is meant to help us write fast, safe software

Fast, maybe. Safe, not really.

On the contrary, code that needs to do integer-to-pointer casts is almost exclusively written in C and C++. Hardware features such as PAC and CHERI were designed to work with those languages assuming that integer-to-pointer casts are possible. Any extension that prevents pointer tagging, extracting signatures, and the like is dead on arrival. Most code doesn't need to touch this kind of stuff, but the whole point of the languages is that it lets you do this when you need to.

The Rust APIs mentioned in the OP support things like pointer tagging without exposing a raw integer address to the user. AIUI CHERI had to bend over backwards to support these operations in C, not because it wanted to but because it had to out of pragmatism. I wager that the CHERI authors would be thrilled if the grandparent's proposal to disallow int2ptr casts were possible to implement without ruling out every significant C codebase in history.

I understand what you’re saying but I think we’re talking about two separate contexts, I’ll call them “CHERI unaware” and “CHERI aware”. There’s plenty of low-level, pointer casting CHERI unaware code, that should continue to work on the hardware. But there’s also people who write secure systems on top of it, and would like to do so in C and C++, so it’s important that they are able to access tags and such. Whether that is through wrappers over assembly instructions, or compiler intrinsics, or whatever, but the easier it is to use from high-level code the more likely it will see adoption there.

Well one reason I think is the following pattern in some library.

  struct SomeStruct {
    ...
    void (*callback)(A);
    A user_data;
  }

Here A will be either int or void*. But regardless of stated type, the expectation is that the user puts whatever they find the most convenient there, whether thats a pointer or integer (fd maybe?).

> When an integer is cast to pointer in those schemes, the pointer can become invalid

Doesn't that mean the compilers are non-compliant? uintptr_t is defined in terms of supporting round-trip conversions, no?

Reply on news.ycombinator.com