Hacker News Reader

Sounds like just a common mistake where people used the "stack" accidentally.

Ex:

    struct someStruct* badfunc(){
        struct someStruct toReturn;
        toReturn.a = foo();
        toReturn.b = bar(); 
        return &toReturn; 
    }

In most people's code, this would probably work...

    struct someStruct a = *badfunc();
    func2(); // This will overwrite the "toReturn" 
             // from the last call, but as long as the 
             // struct was copied before any other function 
             // call, you're probably fine though in
             // undefined-behavior land

-----------------

Either that, or you're talking about strtok (and other non-reentrant functions).

It was definitely malloc'd memory, as I remember removing free() calls from the callee and adding them to the caller.

That's the old "source/sink" pattern.

"Source" functions return a malloc'd pointer. You have to manually call free on it, or pass it to a "sink" function (which internally calls free). In C, this is seen in strdup.

C++ took this pattern and formalized it into auto_ptr<>, and later unique_ptr<> when RValue references became a thing in C++11.

I’ve used this before in embedded code to save rom space by not having to include malloc. The stack _is_ the heap! Just have to be very careful about when you can call another function.

The best version of this is where you allocate a block on your stack then pass that as a pointer up to the next function to use. The one who owns the memory is the one who allocates it (Rust style?). Or, have the linker allocate global blocks works too.

Just bump the stack pointer after call to function and use the allocated memory without risk of overwrite, like alloca() does.

Question, why would this "probably work"? I would have agreed with your assessment if `a` was used for its one and only purpose before `func2` was called ... but as it stands as soon as `func` is called, the content of `a` will most likely be replaced by garbage (and therefore definitely will not "work" in any reasonable sense of the word), no?

Or do you mean something else by "probably work"? (like, in the sense that it will output "something").

Since func2 doesn't have any parameters, the only thing that calling it will put on the stack is the return address. In fact, if it's the last function call in the code block, even that might get optimized out. The struct should be intact and available via a local variable in func2.

It's because `a` is not a pointer to the result of badfunc; it is a copy. So the return value of `badfunc` might be overwritten if func2 is non-trivial, but the copy will not.

Man this sounds like something some students came up with after partaking in the ganja. And it coming out of Berkeley in the 80s certainly tracks with that...

Not a good way of doing things. I mean, have fun using Valgrind. Or switching out libc, etc. And what about key material? There you would still have to do a second step of zeroing or junking the memory when done with it anyway.

Yes, grad students at Berkeley in the early 1980s. For some reason I associate this technique with Bill Joy (who obviously was a major influence on a lot of what went into the 4bsd releases). However I have no evidence of this, nor whether any or what kinds of substances might have been involved.

It also fails on multithdreaded programs, unless you add even more assumptions on the allocator.

"Multidreaded programs" :-)

This was at least a decade before multithreading in C and Unix. But yes this "technique" would have failed miserably in a multithreaded environment.

I mean, it wouldn't even work with interrupts, technically (though an interrupt that plays "nice" shouldn't allocate).

In GC languages a common approach is to have "finalizers" to make something like this a possible and sometimes convenient way of dealing with a foreign API, I wonder if what you saw was something similar? The idea is to allocate the foreign memory, then make a finalizer which is just a hook that will (eventually) call the foreign free only when some object (like a wrapper for the foreign memory) is collected. Something similar could be hidden behind some preprocessor macros, with guarantees only until the next OUR_MALLOC...

The problems for the GC languages tend to be fewer but if the wrapper is out of scope but someone grabbed and maintains a hold on the foreign memory directly, they're playing with fire as for when the GC will execute the finalizer hook and make that memory invalid. It's also a frustrating technique when foreign APIs -- particularly in certain graphics contexts -- require allocation threads to be the same as freeing threads, and of course depending on the implementation of free and the GC it might be an expensive operation to have a bunch of them suddenly happen at once when all you were expecting was a new native object and not a bunch of GC work behind the scenes.

Definitely not GC. This was K&R C on BSD Unix around 1984.

That is why finalizers are yesterday solution, most modern GC based languages have eventually catched up with Common Lisp and offer region based resource management (try-with-resources, use, using, defer, with,...), and in some cases trailing lambdas, which completly hide the resource management from the consumer.

For scenarios like you're describing, .NET has SafeHandles for example.

Sounds like it was just using the heap to badly imitate returning variable-length data on the stack under a callee-preserved calling convention. (Callee writes the variable-length data inside their own stack frame, pops the stack frame in the function epilogue, and “leaks” the pointer and size of the data in caller-expected return registers. Caller uses the dangling data — carefully not pushing to the stack until it has finished. Everything works out.)

> I'm convinced there was another style of C API where the callee would malloc a struct, populate it, and free it immediately before returning a pointer to it. Of course, the only way the caller can use the result is after it has been freed.

That's more than a bad API design, that's undefined behavior -- squarely in nasal-demons territory. Depending on the compiler, the callee, the caller, or the entire observable universe can be optimized away into a no-op.

Well, this sounds like it was before ANSI C, so there was no defined notion of undefined behaviour - I think that term of art came with the later standardisations. And if it was written to run on a specific OS or compiler (4BSD), one can argue that it was a really bad design, but it worked reliably on what was essentially the implementation-defined platform it was targeting.

Oh yes, totally undefined.

But consider the time frame, early 1980s K&R C on 4bsd Unix on a VAX. This predates ANSI/ISO C and Posix. It even predates “nasal demons.” There was no specification; or perhaps the implementation was the specification. The fact was that at some point the bsd allocator did leave freed memory untouched until the next memory allocation operation, and so people wrote programs that relied on this.

Again, I’m not defending this, but this seemed to be the way that some people thought about things. I even remember questioning some code that used memory after having freed it. It was explained to me that this was “safe” because the memory wouldn’t be modified until the next malloc!

Also, remember that BSD was the system where if you did

    printf("%s", NULL);

it would print “(null)” instead of getting SIGSEGV. And in general, deferencing a null pointer would return zero. The rationale for this was that it “made programs more robust.” (Again, I disagree, don’t argue with me about this!)

One more common technique from the BSD era (srogue again, but other programs did this too). To save the state of a program, write to a file everything between the base of the data segment to the “break” at the top of the data segment. To restore, just sbrk() to the right size and read it all back in, overwriting everything starting at the base of the data segment. I always found it surprising that this worked, but it worked often enough that people did sh!t like this.