Hacker News Reader

Comment by ghoward | Hacker News Reader

TFA is right, sadly.

One of the projects I was to go in the future is implement boringcc [1], and this sounds like something I would want in it.

The question then becomes: would it even be possible to do?

[1]: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...

View on HN

The spam on that thread is really something.

Wouldn't the majority of it just be, effectively, "all pointers are now fat"?

It could disable some (many?) optimizations, but I don't see it as a particularly hard thing to do (at least conceptually).

No, not a hard thing to make a boringcc compiler, but I was referring specifically to querying stack size.

TFA is wrong. The C run-time's call frame allocation method and actual resource limits leak past the C function call and variable-length-array (VLA) abstractions. You can write portable code to force defined (by the platform, not by the C spec) resource exhaustion behavior sooner than undefined behavior caused by memory corruption caused by use of much-larger-than-the-stack stack allocations.

Can you really? If you depend on a SIGSEGV handler, that handler needs stack space unless you set up a separate stack for it, and I am not sure that is portable.

The point is to cause a defined (by the platform) stack exhaustion failure mode before possibly causing undefined behavior by corrupting memory.

The C specs do not define any resource exhaustion failure modes. But actual operating systems, ABIs, platforms -- they do.

If you are on a system that gives you a SIGSEGV but no way to catch it on an alternate stack -or if you don't catch or ignore it- then your process will crash. This is fine. It's better than memory corruption.

Can you give me an example of a platform where your program cannot cause memory corruption if you access an array on the stack out of bounds far enough to corrupt actual existing memory on the heap? Because a SIGSEGV is the best case scenario; the other scenarios are not helped at all by platforms.

Say you alloca(1GB), and alloca() is naive and gives it to you even though that 1GB spans several other stacks, and now you write somewhere in the middle. If you're lucky you'll hit unmapped space and trigger a segfault. If you're unlucky you'll scribble over another thread's stack or whatever.

But if you progressively write into the alloca()ed area in the direction of stack growth then you cannot corrupt other mappings, and you can only segfault if you exceed your stack's maximum size. Of course, there can be platforms with no SIGSEGV or whatever.

Probably the only way is to use platform-specific quirks, but that's basically the same with everything else. The portability only works for some generic code, pretty much any non-trivial/real-world software uses a lot of platform-specific code.

Reply on news.ycombinator.com