Conversation

Notices

1. Embed this notice
   :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 13:36:26 JST :umu: :umu:
   lcc: "arch/e2k/boot/dts/include/iohub.dtsi", line 113: error #11: unrecognized
   preprocessing directive
   #size-cells = <2>;
   
   
   ah yes
   
   wonders of using C preprocessor in device tree language
   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 04-Sep-2025 13:36:45 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @a1ba Sometimes I wonder which is more cursed, gnu variant of m4, or C preprocessor for non-C.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 04-Sep-2025 13:47:13 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @a1ba Meanwhile I ignore the hell out of #pragma because there's usually better ways of doing it (like testing if compiler supports a compile flag).
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 13:47:14 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan what compiler even supposed to do with unknown directives.
     
     I know they can ignore #pragma and that's what they should do.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 13:51:01 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan I've even seen some put shit like #ifdef _MSC_VER #pragma once #endif
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 13:51:02 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan the only really useful pragma I know and which is standardized is openmp :)
     
     some insane people like to put #pragma once (I was there too) but it's useless and doesn't even affect build times.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 04-Sep-2025 13:54:39 JST Haelwenn /элвэн/ :triskell:

     in reply to

     @a1ba Yeah, regular #ifndef _HEADER_H header guards makes more sense.

     Or just no header guards, which is typically what I do unless it's a public header you're supposed to #include in an application.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 04-Sep-2025 14:02:36 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @a1ba Order of includes is so annoying, in fact it bit me yesterday with Tcl headers…
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 14:02:37 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan I got bitten by HLSDK code where changing the order of includes breaks build so hard, so I tend to make headers compile-able, which in turn increases odds of double-triple includes, so header guards are required.
     
     Or just put everything into one shared header lol that works too.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 04-Sep-2025 14:07:00 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @a1ba No sure if it's purely Tcl, I hit it trying to fix a vendored version of expect for modern gcc/clang.
     And expect might be doing weird shit.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 14:07:02 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan is that a problem of tcl itself? Ouch.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 14:34:57 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan so the answer is the -xassembler-with-cpp flag
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Thursday, 04-Sep-2025 14:34:58 JST :umu: :umu:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan clang just strips them away lol
     
     I never questioned how gcc preprocesses device trees so I dunno how it works