Hacker News Reader

Comment by dwattttt | Hacker News Reader

> the program continued using the same pointer, not the realloc call result, since the old pointer did not change

> In this context, it is a bug in the application

This is a non-intuitive result by the normal lens C pointers are viewed by; these two pointers compared equal, how could using one differ from using the other? Pointer provenance rears its ugly head here though; one of those "pointers that have the same value"'s provenance is different to the other. By the standard, they _are_ allowed to be treated differently, and honestly the standard requires it.

https://www.ralfj.de/blog/2020/12/14/provenance.html is pretty accessible, and shockingly on point: "just because two pointers point to the same address, does not mean they are equal in the sense that they can be used interchangeably".

EDIT: spelling

View on HN

Provenance might be used as justification now but the actual rules are simpler and stricter. After freeing (or reallocing) a pointer, the application must not inspect the pointer value anymore. Even `new_pointer == old_pointer` is not allowed.

IIRC, one justification for this was to account for systems with non-flat memory where inspecting the value of the old pointer might cause a processor exception.

It also makes sense for an allocator that can satisfy new allocations with recently freed allocations.

> Even `new_pointer == old_pointer` is not allowed.

This is legal. But dereferencing old_pointer even after this check had passed is undefined.

No, it is not, and it has never been OK for as long as C has been standardized by ANSI or ISO.

C89 says that "The value of a pointer that refers to freed space is indeterminate." and that behavior is undefined "upon use ... of indeterminately-valued objects", hence a compiled program can e.g. behave as if `new_pointer == old_pointer` even though the object was relocated in memory.

That standard says free takes a void*, i.e. it takes the pointer by value, and that passing values by value to a function prevents the callee from changing them.

More literally, your pointer value is copied into a register before the call into libc, so free can't change the value even if it wants to. Realloc can't either for the same reason.

That provenance has come up with the premise that a ! = a for a 64bit integer value is an error in the formalism, specifically the language is deliberately inventing things that cannot be so on hardware.

Note that (a) pointer representations can contain bits representing the provenance that don’t participate in equality comparison, and (b) a “C implementation” in terms of the C standard includes the compiler, which means the compiler is allowed to track pointer provenance statically even when the representation in memory doesn’t differ (e.g. exactly what GCC is doing here). In addition, a C implementation is also allowed to track pointer provenance externally at runtime, again even if the pointer representation (as exposed by memcpy into a char buffer) is the same.

To the extent that your compiler has embraced the provenance model, yes. But that does mean that you can't assume that the language pointer is the one the machine gave you and therefore probably can't write code that does anything with pointers other than pass them around as opaque handles. No testing their alignment, no comparing them to each other.

> specifically the language is deliberately inventing things that cannot be so on hardware

So what? The standard has "undefined behavior"; real implementations always do something, even if that something cannot be determined in advance. The standard is the standard, it's not a machine.

Well, at some point in history C was about telling a physical machine what to do. You can see that in the operations it exposes.

I don't know what modern C is for. The one that manipulates an abstract machine with concurrency oracles and time travelling metadata on object identifiers. It looks like an aberration derived from C++ to me.

Every compiler for C has always done things like register allocation that make it not assembly.

Huh, okay, I didn't know that, but apparently it is true.

Using clang, program #1:

    #include <stdio.h>
    #include <stdlib.h>
    int main(int argc, char **argv) {
        void * p = malloc(123);
        void * q = realloc(p, 200);
        printf("%p == %p -> %i\n", p, q, p == q);
        free(q);
        printf("%p\n", q);
        return 0;
    }

prints out:

    0x5f867a8a9300 == 0x5f867a8a9300 -> 1
    0x5f867a8a9300

Program #2: (only difference is the extra printf after malloc)

    #include <stdio.h>
    #include <stdlib.h>
    int main(int argc, char **argv) {
        void * p = malloc(123);
        printf("%p\n", p);
        void * q = realloc(p, 200);
        printf("%p == %p -> %i\n", p, q, p == q);
        free(q);
        printf("%p\n", q);
        return 0;
    }

prints out:

    0x5bcba8225300
    0x5bcba8225300 == 0x5bcba82257a0 -> 0
    0x5bcba82257a0

So if we print out the pointer before reallocation then they're not equal, but if we don't then they are equal.

Funny enough, "-fsanitize=undefined" doesn't seem to detect this. Neither does "-fsanitize=address" (but with ASAN the results are now consistent and in both cases compare to not equal).

If the standard says it is invalid then they better make the value of the variable holding the pointer invalid

But the malloc/free interface is one of the most badly designed interfaces in the C lang it's not even funny

They have made it invalid. You’re not supposed to do it.

Wow, look, move semantics! An advanced compiler could even check for that...

Would it be acceptable to save the old address as a uintptr_t before the realloc(), and compare it with the new one after?

You could do it legally, but the results are not required to be what you want them to be.

This is only ever a problem in hosted C and its standard library malloc and free, right? If you write freestanding C with your own memory allocator you made from scratch, then the compiler will never make such assumptions. Right?

That wheel is certainly in need of some serious reinvention anyway. This seems like a good starting point:

https://nullprogram.com/blog/2023/12/17/

It doesn't mean that but maybe it actually should. The fact these perfectly good intuitions don't apply because of completely irrelevant reasons is a huge cause of friction and bugs.

Your article contains the perfect example:

> UB on integer overflow is a compiler-only concept

> every target supported by the compiler will do the obvious thing and just produce an overflowing result

Pretty much every computer that matters works the way you expect it to: the value will overflow, some flag will be set, etc. The compiler couldn't care less though. The compiler decrees that it shall be undefined. You know it works but it doesn't because the compiler refuses to do what you expect it to do because it's "undefined".

Well then just define it for god's sake. I'm so tired of the uncertainty. Tired of playing these games with the compiler. Undefined? I don't even want to read that word ever again.

Let's define this right now.

  -fwrapv

There. It is now defined to be what everyone expects and wants. Now the optimizer won't be getting "clever" with this and generating complete garbage code as result. The compiler's optimizer is no longer your enemy in this case. It won't be erroneously optimizing entire loops to some random constant anymore. One would think they'd emit a warning instead in these cases but no.

Strict aliasing is yet another massive pain that you need to deal with because of compilers and their "optimizations". People have actually told me to "launder" pointers through asm statements so the compiler can't make nonsense assumptions about that stuff.

This is C. We do things like write memory allocators. Of course we're going to alias stuff. I have a structure type, I have a byte buffer with the data, of course I want to overlay the type on the byte buffer and just access it directly. Why is it that the compiler just doesn't let me reinterpret memory however I want? Compiler has no business making my life hell because of this.

Turns out the C standard prescribes some "strict aliasing" nonsense because Fortran has it or some other reason nobody really cares about. If you're doing anything at all in C you're probably violating this.

  -fno-strict-aliasing

There. You can now do what you want to do without the compiler getting all clever about it and ruining your day with nonsense code generation. Now it won't be reordering your code into nonsense just because it can "prove" that two pointers can't be equal even though you literally assigned one pointer to the other.

Over time I've built up this little collection of C compiler flags and they've become unconditional overrides in all my makefiles. No matter what users pass in via CFLAGS or whatever, these little things still get disabled. I have no idea what the performance impact is and honestly I don't care.

There's quite a lot of documented compiler flags, I couldn't evaulate every single one of them. If anyone here knows of any other useful flags that define the undefined, please reply to this comment. I'll add them to my makefiles without thinking twice.

It’s been a long time since I worked with C, but my recollection was that a) strict aliasing allows for optimizations that are actually worthwhile, and b) it’s really easy to type pun in a defined way using unions anyway.

> strict aliasing allows for optimizations that are actually worthwhile

I don't think there are many sensible, real world examples.

A nice explanation of the optimizations the strict-aliasing rule allows: https://stackoverflow.com/a/99010/66088

The example given is:

    typedef struct Msg {
        unsigned int a;
        unsigned int b;
    } Msg;

    void SendWord(uint32_t);

    int main(void) {
        // Get a 32-bit buffer from the system
        uint32_t* buff = malloc(sizeof(Msg));

        // Alias that buffer through message
        Msg* msg = (Msg*)(buff);

        // Send a bunch of messages
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff[0]);
            SendWord(buff[1]);
        }
    }

The explanation is: with strict aliasing the compiler doesn't have to think about inserting instructions to reload the contents of buff every iteration of the loop.

The problem I have is that when we re-write the example to use a union, the generated code is the same regardless of whether we pass -fno-strict-aliasing or not. So this isn't a working example of an optimization enabled by strict aliasing. It makes no difference whether I build it with clang or gcc, for x86-64 or arm7. I don't think I did it wrong. We still have a memory load instruction in the loop. See https://godbolt.org/z/9xzq87d1r

Knowing whether a C compiler will make an optimization or not is all but impossible. The simplest and most reliable solution in this case is to do the loop hoisting optimization manually:

        uint32_t buff0 = buff[0];
        unit32_t buff1 = buff[1];
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff0);
            SendWord(buff1);
        }

Doing so removes the load instruction from the loop. See https://godbolt.org/z/ecGrvb3se

Note 1: The first thing that goes wrong for Stackoverflow example is that the compiler spots that malloc returns uninitialized data, so it can omit the reloading of buff in the loop anyway. In fact it removes the malloc too. Here's clang 18 doing that https://godbolt.org/z/97a8K73ss. I had to replace malloc with an undefined GetBuff() function, so the compiler couldn't assume the returned data was unintialized.

Note 2: Once we're calling GetBuff() instead of malloc(), the compiler has to assume that SendWord(buff[0]) could change buff, and therefore it has to reload it in the loop even with strict-aliasing enabled.

How does the version with buf0 and buf1 work? It looks like it sends always the same two values...

Hmmm, yes. I didn't understand what the code did.

Instead of creating those buff0 and buff1 variables before the loop, I should have done:

    for (int i = 0; i < 10; ++i) {
        unsigned a = i;
        unsigned b = i+1;
        msg->a = a;
        msg->b = b;
        SendWord(a);
        SendWord(b);   
    }

That gets rid of the load from the loop. https://godbolt.org/z/xsqWfxKzd

The strict aliasing stuff allows you to do "optimisations" across translation units that are otherwise unsound.

The compiler alias analysis is much more effective than those rules permit within a translation unit because it matters whether int* alias other int*.

And then we have link time optimisation, at which point the much better alias analysis runs across the whole program.

What remains therefore is a language semantically compromised to help primitive compilers that no longer exist to emit slightly better code.

This is a deeply annoying state of affairs.

Aliasing analysis is quite helpful for sophisticated compilers to generate good code.

Alias analysis is critical. Knowing what loads and stores can alias one another is a prerequisite for reordering them, hoisting operations out of loops and so forth. Therefore the compiler needs to do that work - but it needs to do it on values that are the same type as each other, not only on types that happen to differ.

Knowing that different types don't alias is a fast path in the analysis or a crutch for a lack of link time optimisation. The price is being unable to write code that does things like initialise an array using normal stores and then operates on it with atomic operations, implement some floating point operations, access network packets as structs, mmap hashtables from disk into C structs and so forth. An especially irritating one is the hostility to arrays that are sometimes a sequence of simd types and sometimes a sequence of uint64_ts.

Though C++ is slowly accumulating enough escape hatches to work around that (launder et al), C is distinctly lacking in the same.

Alias analysis is important. It's the C standard's type-based "strict aliasing" rules which are nonsense and should be disabled by default.

This is C. Here in these lands, we do things like cast float* to int* so that we can do evil bit level manipulation. The compiler is just gonna have to put that in its pipeline and compile it.

The optimizations can easily be gained back by "manual" loading and storing to temporary local variables.

The classical:

  int foo(float *f, int *x) {
    *x = 2;
    *f = 3.0f;
    return *x; // oh no, without typed based aliasing I have to load x again!
  }

Can obviously be rewritten to:

  int foo(float *f, int *x) {
    int z = 2;
    *x = z;
    *f = 3.0f;
    return z; // ah, thank you programmer, z has not had its address taken, it's obviously 2.
  }

That code does not violate the aliasing rules in any case.

The two functions you wrote are not the same; the first re-reads *x which may return a different value than 2 if *x was modified in between the first and third lines of the function by another thread (or hardware). However, since x is not marked volatile, the compiler will usually optimize the first function to behave the same as the second.

Type punning with unions was actually forbidden by C89. You were only ever supposed to read the union member which was last written to. This may have been relaxed in C17; I can only find a draft online, but it allows for type punning in unions as long as the member being read is not longer in size than the member last written to.

IIRC it was supported in C89 and described as implementation-defined and C99 changed the wording and mentions union type punning.

What the standard says doesn't really matter. Only what major compilers do matters. GCC has decreed that type punning through unions is supported, therefore it might as well be standard.

> I have no idea what the performance impact is and honestly I don't care.

Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

Perhaps you use C because you must interact with other C code; many languages have quite usable C FFI. If you must use C because your code is part of another project (e.g. the Linux kernel), you don't have control over the flags anyway. If you must use C because of low memory availability (e.g. a microcontroller), then perhaps fine — but that's quite niche. (And there's always Rust.)

C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

It was by exploring UB to the extreme those compilers optimizers do nowadays, that such language finally got the fame it has 40 years later.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

The 21st century renaissance of high level languages got us somewhat back on track.

> C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

I think that's not especially relevant. The issue is that most other higher level programming languages had poorer performance and/or inserted undesirable mysteriously-timed lags in performance. Fortran had excellent performance, but Fortran at that time couldn't handle many constructs that C can. Some Common Lisp implementations at the time had reasonable performance, but the garbage collectors often inserted pauses (ugh!), and many were expensive at the time too.

Also: The 1980s was the rise of the IBM PC-compatible (and the Macs too). These were machines whose underlying chips matched C decently well (they had hardware-implemented large stacks unlike the 6502), however, these machines were underpowered compared to what some people wanted them to do. This also had a rise in Unix servers, where C was their native tongue.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

This goal seems somewhat oxymoronic - if the "goal" is to be keenly aware of what the compiler will do and double check all assembly, then you shouldnt use C. If the goal is to ignore assembly and not pay attention to these sorts of things, then you shouldnt use C.

The only valid niche I see is where the goal is to use C, not really have to worry about the assembly, have it do the "right" thing on your platform. I.e. no undefined behavior, just underperforming (and called out as such). Then you can go in and "approve" various optimizations.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

If performance is your top priority C is also the wrong choice.

What would you suggest instead?

If you are writing general purpose software, I would suggest Rust if I have nothing else to go on, although there are plenty of other good choices if you know more about the problem.

In a few cases there is today a special purpose language for the kind of thing you're writing which will knock both C and Rust on their backs for performance because it was never trying to do anything else.

I think C is still a good choice for the following reasons: - Performance is generally very good and while special languages can sometimes be better it usually easily possible to get the C code to the same level. - But with special languages you will often run into limitations where you are stuck. - It has long term stability - Compile-times are short which I really like - There are good tools - It has very good interoperability with everything - The code an easily be reused from most other languages, so it does not tie you into a specific framework - etc..

I write C because I like C. That's the only reason I've got. It's what I feel comfortable writing code in. I tried learning Rust but I just couldn't get used to it.

I like C where I write the functions and the structures and the compiler just translates it to the simple processor instructions you expect it to. No complicated hidden machinery under the hood, just simple unmangled symbols pointing at simple code that conforms to simple ABIs. This simplicity is also the reason the so called "C ABI" is so ubiquitous.

Another reason I write C is it's one of very few languages with freestanding code support. I only write freestanding C targeting the Linux kernel-userspace ABI. In my opinion C is a much nicer language without the libc and its legacy. I really enjoy it.

> It won't be erroneously optimizing entire loops to some random constant anymore. One would think they'd emit a warning instead in these cases but no.

It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

> This is C. We do things like write memory allocators. Of course we're going to alias stuff. I have a structure type, I have a byte buffer with the data, of course I want to overlay the type on the byte buffer and just access it directly. Why is it that the compiler just doesn't let me reinterpret memory however I want? Compiler has no business making my life hell because of this.

char is allowed to alias other types. Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

> Turns out the C standard prescribes some "strict aliasing" nonsense because Fortran has it or some other reason nobody really cares about. If you're doing anything at all in C you're probably violating this.

No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

None of these things are the compiler fighting you. In fact it is trying to help you. But you seem to want something closer to high-level assmebler and you can have that: don't use and optimizing compiler or use flags to change the language semantics to your taste. That doesn't make the default semantics bad though.

> I have no idea what the performance impact is and honestly I don't care.

Then C and C++ are simply not made for you. There are plenty of "safe" languages for people who don't care about the perfomance impact.

> If anyone here knows of any other useful flags that define the undefined, please reply to this comment. I'll add them to my makefiles without thinking twice.

Try -O0.

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Hmm, could possibly include optimization flags directly into the source code (would be clearer and less compiler mess perhaps). I could also see this causing other issues...

Most compilers have (non-standard) constructs to control optimizations

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Yeah. That's sad but there's nothing that can be done about it. If you write C you're basically guaranteed to violate strict aliasing at some point and I just cannot handle the uncertainty anymore. The Linux kernel developers are much smarter than me and as far as I know they reached the same conclusion as I did: this aliasing stuff is not even worth enabling.

I know there's a may_alias attribute you can apply to pointers to warn the compiler but I'm not confident in my ability to do it 100% correctly. I have a feeling it'd end up getting applied to a significant chunk of the code anyway, might as well just turn it off.

> char is allowed to alias other types.

I know. But can uint8_t? It's basically the same type as unsigned char but it's still a distinct type in the compiler's eyes. Never found a definitive answer to that question. What if you define your own u8 type?

I know for a fact uint16_t can't safely alias anything. Implementing a 16 bit hash function? Hoping to just treat an arbitrary buffer as an array of u16? Not gonna happen unless you turn off this aliasing nonsense.

> Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

I shouldn't have to copy huge buffers all over the place just to get the compiler to generate the simple instructions I want. This is on the same level as the "pointer laundering" advice I've received. Oh just pass the pointer through some inline assembly, compiler can't see into it so it assumes anything can happen and it won't screw up the code trying to optimize. This memcpy is just yet another thing the compiler can't see into. The proper solution is to kill the problematic optimizations.

> No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

It doesn't have to be that way. I statically link all my code, enable link time optimization, pass flags like -fwhole-program. Surely the compiler can analyze the entire program and statically determine that certain pointers do not alias.

I have a memory allocator that works with a huge statically allocated byte buffer as its backing memory. Surely the compiler can determine that all pointers returned by my memory allocation functions are subsets of that buffer and that they do not necessarily alias each other.

> use flags to change the language semantics to your taste

That's exactly what I was advocating for in my post.

> That doesn't make the default semantics bad though.

I would argue that they are extremely bad. Compilers will straight up delete overflow and null checks from your code if the conditions are right. This can cause it to "optimize" entire functions into literally nothing. There's just no way anyone can convince me that this is not adversarial, if not malicious.

> Then C and C++ are simply not made for you.

C was made to support the development of Unix. I'm writing similar low level Linux operating system stuff. I'd say I'm closer to the target audience than all these speed obsessed folks ever were.

> There are plenty of "safe" languages for people who don't care about the perfomance impact.

I absolutely do care about performance in general.

I said I don't care about the performance impact of that one flag. Adding that flag buys me the certainty that the compiler won't screw the code up based on absolute nonsense assumptions that I don't ever want it to make. I've made the decision to not care in this case. I absolutely do want all the other optimizations the C compilers will give me.

And I don't want "safe", I want "sane".

Things like signed integer overflow not being C's particularly idiotic "can't ever happen, please delete any checks" flavor of undefined falls under my definition of "sane". I also consider overlaying a structure on top of a byte buffer to be such a basic operation there's no point in using C at all if the compiler is gonna screw this up.

> Try -O0.

No. That disables too many useful optimizations that are not problematic in any way whatsoever.

>> Pretty much every computer that matters works the way you expect it to: the value will overflow, some flag will be set, etc. The compiler couldn't care less though.

And RISC-V drops the hardware flags entirely. I questioned this when I read it, but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days. None of the flags are accessible from C either so they just dropped them and things seem to be going well!

> but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days

Funny you mention that. I'm studying math and algorithms to implement the arbitrary precision integer support for my programming language. The word "carry" is showing up a lot in my research so that bit does seem to be an incredibly useful feature and I have no idea why they'd remove it.

> None of the flags are accessible from C either so they just dropped them and things seem to be going well!

I know you can't directly access those flags but the fact is compilers do provide their functionality to programmers via builtins.

For example:

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

Those builtins will cause the compiler to generate optimal instructions such as conditional jumps that depend on the carry or overflow bits.

I used the __builtin_mul_overflow function to check for overflow in my memory allocation code.

This is what we really want. We want to handle these conditions, no matter how they're implemented. This is a perfectly acceptable way for the compiler to expose these processor features in a way that makes sense to us programmers. In the case of RISC-V, GCC will just emit whatever code is appropriate for checking overflows on that processor.

What's definitely not acceptable is for the compiler to just go "aw man look at this USELESS overflow checking code over here, AS WE ALL KNOW signed integer overflow is UNDEFINED and therefore CANNOT EVER HAPPEN, why the hell is this shit for brains programmer checking for a thing that can't happen, I'll just go ahead delete this nonsense code literally right now, oh wow would you look at that, looks like I just optimized the entire program into a noop, I must be the best compiler in the universe".

> Pretty much every computer that matters works the way you expect it to

Except the ones that saturate, that produce trap values, etc.

Reply on news.ycombinator.com