4 ms·

the only result of banning VLAs is to force everyone to use alloca, which is even less safe. exhibit A: https://lists.freedesktop.org/archives/mesa-commit/2020

• tedunangst 4y ago
  Nobody is forced to use alloca, which is not less safe, only equally disastrous. Just use malloc, already.
  • jcelerier 4y ago
    ah yes, why didn't I think of it, let me just try: #include <cstdlib> #include <span> __attribute__((annotate("realtime"))) void process_floats(std::span<float> vec) { auto filter = (float*) malloc(sizeof(float) * vec.size()); /* fill filter with values */ for(int i = 0; i < vec.size(); i++) vec[i] *= filter[i]; free(filter); } $ stoat-compile++ -c foo.cpp -emit-llvm -std=c++20 $ stoat foo.bc Parsing 'foo.bc'... Error #1: process_floats(std::span<float, 18446744073709551615ul>) _Z14process_floatsSt4spanIfLm18446744073709551615EE ##The Deduction Chain: ##The Contradiction Reasons: - malloc : NonRealtime (Blacklist) - free : NonRealtime (Blacklist) oh noes :((
    • tedunangst 4y ago
      Here's a nickel, kid. The bullshit about oh my embedded systems doesn't have dynamic memory is bullshit. You either know how big your stack is and how many elements there are, and you make the array that big. Or you don't know and you're fucked. You can't clever your way out of not knowing how big to make the array with magic stack fairy pretend dynamic memory. You can only fuck up. Is there room for 16 elements? The array is 16. Is there room for 32? It's 32.
      • dataflow 4y ago
        I think the parent comment was about malloc not being real-time? Not about storage space. Though I do wonder why there can't be a form of malloc that allocates in a stack like fashion in real time to satisfy the formal verifier?
        • kllrnohj 4y ago
          Real time also generally means your input sizes are bounded and known, otherwise the algorithm itself isn't realtime and malloc isn't the reason why. But strictly speaking the only problem is a malloc/free that can lock (you can end up with priority inversion). So a lock-free malloc would be realtime just fine, it doesn't have to be stack growth only.
          • dataflow 4y ago
            > Real time also generally means your input sizes are bounded and known, otherwise the algorithm itself isn't realtime and malloc isn't the reason why. I think you meant to say something else? Real-time is a property of the system indicating a constraint on the latency from the input to the output—it doesn't constrain the input itself. (Otherwise even 'cat' wouldn't be real-time!)
            • ordu 4y ago
              If your input is not bounded you can't know in advance the time needed to process it. In other word you cannot be realtime. `cat` can be realtime, but only by fixing the size of its internal buffer where it reads to and writes from. In this case it can in theory bound the time needed to process the fixed block of input. But if for some reason `cat` tried to read/write by lines of unknown in advance size, it would fail to be realtime.
              • dataflow 4y ago
                I think we're not disagreeing on the actual constraints, but the terminology. The "internal buffer" is not part of the system's "input". It's part of the system's "state".