4 ms·

Unfortunately, this requires an executable stack, and only works on gcc, though an alternate implementation can work on clang. After a few attempts at defer, I

Unfortunately, this requires an executable stack, and only works on gcc, though an alternate implementation can work on clang. After a few attempts at defer, I ended up using a cleanup macro that just takes a function and a value to pass to it: https://github.com/aws-greengrass/aws-greengrass-lite/blob/8fea9e7dae75e20e026b42345a2347dd424371f8/ggl-lib/include/ggl/cleanup.h#L15 https://github.com/aws-greengrass/aws-greengrass-lite/blob/8... Since the attribute or a function-like macro in the attribute position broke the c parsing in some tooling, I made the macro look like a statement.

uecker 2y ago
It does not need an executable stack: https://godbolt.org/z/K1GTa4jh4 https://godbolt.org/z/K1GTa4jh4
- accelbred 2y ago
  The macro from the article uses nested functions which on gcc are implemented with tramolines that need executable stack. https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...
  - uecker 2y ago
    The trampolines are not generated in this case.
    - eqvinox 2y ago
      To be fair you're not communicating very well — there are no trampolines being used here because the call site is directly in the same function, so no trampoline is needed with already being in the correct stack frame. (And also on -O1 and higher the entire call is optimized out and the nested function inlined instead.)
      - uecker 2y ago
        Fair, I was not explaining why the statement was wrong. Anyhow, the trampoline is not related to the call site being in the same function but whether a pointer is generated to the nested function and escapes. Nested functions in general do not need trampolines or executable stack.
        accelbred 2y ago
        Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.
        Gibbon1 2y ago
        I've used nested functions for a very long time with gcc and they are completely reliable. Since my code is embedded without an MMU the oh noes executable stack doesn't fill me with any dread. It's unfortunate a lot of the standards guys are horrified by anything that isn't C89. Because if the executable stack is an issue it's worth fixing. Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies.
        eru 2y ago
        > Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies. Slowing them down is good. And: separating data and code helps simplify managing the caches.
        uecker 2y ago
        One could easily remove the need for trampolines by having a wide function pointer type. In C, this would even be allowed without having a new type, but ABI compatibility makes this not practical. With a new qualifier this would be no problem though. The real reason some people are against it is that it diverges from C++.
deleted 2y ago
[deleted]

uecker 2y ago

It does not need an executable stack: https://godbolt.org/z/K1GTa4jh4 https://godbolt.org/z/K1GTa4jh4

accelbred 2y ago
The macro from the article uses nested functions which on gcc are implemented with tramolines that need executable stack. https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...
- uecker 2y ago
  The trampolines are not generated in this case.
  - eqvinox 2y ago
    To be fair you're not communicating very well — there are no trampolines being used here because the call site is directly in the same function, so no trampoline is needed with already being in the correct stack frame. (And also on -O1 and higher the entire call is optimized out and the nested function inlined instead.)
    - uecker 2y ago
      Fair, I was not explaining why the statement was wrong. Anyhow, the trampoline is not related to the call site being in the same function but whether a pointer is generated to the nested function and escapes. Nested functions in general do not need trampolines or executable stack.
      - accelbred 2y ago
        Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.
        Gibbon1 2y ago
        I've used nested functions for a very long time with gcc and they are completely reliable. Since my code is embedded without an MMU the oh noes executable stack doesn't fill me with any dread. It's unfortunate a lot of the standards guys are horrified by anything that isn't C89. Because if the executable stack is an issue it's worth fixing. Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies.
        eru 2y ago
        > Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies. Slowing them down is good. And: separating data and code helps simplify managing the caches.
        uecker 2y ago
        One could easily remove the need for trampolines by having a wide function pointer type. In C, this would even be allowed without having a new type, but ABI compatibility makes this not practical. With a new qualifier this would be no problem though. The real reason some people are against it is that it diverges from C++.

deleted 2y ago

[deleted]