4 ms·

Clang was made to support GCC extensions and be as close to a drop-in replacement for GCC as possible. Linux misses support for MSVC, Intel C Compiler, XL C and

by tiberius1900 8y ago

Clang was made to support GCC extensions and be as close to a drop-in replacement for GCC as possible. Linux misses support for MSVC, Intel C Compiler, XL C and basically every other C Compiler ever written except for these 2.

saagarjha 8y ago
Clang doesn't support every GCC extension, though. For example, nested functions is something that it doesn't do.
- geocar 8y ago
  Yup. And that one is a deal-breaker for me. Nested functions is exactly how you would write it in assembly. Does anyone know why clang won't support them? "Blocks" are fucking stupid.
  - favorited 8y ago
    Because throwing a trampoline on an executable stack is a hack and a glaring exploitation vector. http://lists.llvm.org/pipermail/cfe-dev/2015-September/045037.html http://lists.llvm.org/pipermail/cfe-dev/2015-September/04503...
    - geocar 8y ago
      Straw man. GCC doesn't use a trampoline for the following code: long f1 (void) { long i = 0; void f2(void) { i++; } f2(); return i; } int main() { return f1(); } So maybe David Chisnall doesn't know what he's talking about? Or maybe he's talking about a specific use case further up the thread. I'm not going to speculate. But to edify on my "Blocks" are fucking stupid throwaway, in clang you can do this: long f1 (void) { __block long i = 0; void (^f2)(void) = ^{ i++; }; f2(); return i; } int main() { return f1(); } which is close enough I could almost paper over the syntax differences with macros, but clang produces unnecessary allocations(!) which are completely unacceptable for my targets and make clang unworkable for me -- even if I could stomach the dogshit assembly that clang produces during testing and continue to use gcc on the packaging server. Surely clang could simply disallow passing the address of the nested function, if it's trying to protect people from themselves?

saagarjha 8y ago

Clang doesn't support every GCC extension, though. For example, nested functions is something that it doesn't do.

geocar 8y ago
Yup. And that one is a deal-breaker for me. Nested functions is exactly how you would write it in assembly. Does anyone know why clang won't support them? "Blocks" are fucking stupid.
- favorited 8y ago
  Because throwing a trampoline on an executable stack is a hack and a glaring exploitation vector. http://lists.llvm.org/pipermail/cfe-dev/2015-September/045037.html http://lists.llvm.org/pipermail/cfe-dev/2015-September/04503...
  - geocar 8y ago
    Straw man. GCC doesn't use a trampoline for the following code: long f1 (void) { long i = 0; void f2(void) { i++; } f2(); return i; } int main() { return f1(); } So maybe David Chisnall doesn't know what he's talking about? Or maybe he's talking about a specific use case further up the thread. I'm not going to speculate. But to edify on my "Blocks" are fucking stupid throwaway, in clang you can do this: long f1 (void) { __block long i = 0; void (^f2)(void) = ^{ i++; }; f2(); return i; } int main() { return f1(); } which is close enough I could almost paper over the syntax differences with macros, but clang produces unnecessary allocations(!) which are completely unacceptable for my targets and make clang unworkable for me -- even if I could stomach the dogshit assembly that clang produces during testing and continue to use gcc on the packaging server. Surely clang could simply disallow passing the address of the nested function, if it's trying to protect people from themselves?