@p And they're also checking the exact sizes rather than say sizeof(size_t) >= 4 which you might want if you need to allocate for more than 4 GiB (which I'd find questionable in samba).
And I could see needing to have it being done at configure time to pick between .c files implementing the same API instead of some #ifdef horror (but in samba it's likely written as an #ifdef horror).
I think the whole treesitter train passed me. Having separate ts major modes for every major mode, that are not derivates any more, makes configuration complex.
I'm not sure if the advantages of treesitter merit the complexity that was introduced into Emacs with this.
Some treesitter modes don't support certain features and I have constantly switch modes.
Perhaps I'll remove treesitter completely for now as I don't see any gains for the moment.
What are your experiences? What features do you get out of a specific treesitter mode that are not available in non-treesitter modes?
@louis You are right with the configuration issue. I hope that will clear up in the future.
Wrt. the question what treesitter-modes do better than their classical counter-parts: they get syntax highlighting, formatting, and navigation right because they know the actual syntactic role of every buffer text. Classical modes use regular expressions and heuristics which cannot work reliably for context-free languages.
And from a language mode writers POV, treesitter modes are easier to write because the hard work is done and maintained somewhere else. For example, the c/c++ treesitter modes are only 1878 LOC whereas the classical cc-*.el files amount to almost 43.000 LOC. Ok, cc-mode also supports java, objective-c, pike, and awk but still.
And it just occurred to me that c-ts-mode supports preprocessor macros nicely, that is, forward-sexp on some #ifdef ... moves point to the closing #endif (which also means that marking preprocessor blocks with expand-region just works). Not so much with the standard c-mode.
Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.
In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).
If a C++ header is intended to be consumed from C, adding the usual #ifdef __cplusplus extern “C” {… should alleviate the name mangling issues.
It's still kinda sad to me how text editors so often fall over completely with a moderately large file. (visual studio code, and 52MB, in today's example)
@dotstdy ...for development, the first thing that falls over is usually syntax highlighting though (e.g. there was a time when dimmed text inside inactive #ifdef/#endif blocks rendered at around 2 frames per second in VSCode)
This might even work. But! Imagine if that condition is missed and the macro is left undefined. What happens to the code that uses this macro?
In C, a call to an undeclared function isn't an error but a warning, and it's often allowed to pass (wtf is -Wall lmao). Adding insult to injury, imagine you build not an executable but a shared library. This way, the error happens... in runtime! Now sprinkle not just one conditional macro but a few dozen, scattered all over code. Make sure that includes order actually matters and that headers to not include each other directly. Now you know how I've spent the past three days.
I fucking hate C. It's a retarded abomination of a language and anyone using it seriously needs to have his genitals cauterised with a glowing hot piece of rebar inserted into urethra.
so _Pragma in c is kinda really stupid, but not only is it stupid, apparently implementations just straight up can't agree on how it should be implemented
first of all, some background: _Pragma is an operator which is processed by the pre-processor. it accepts a string literal, destringizes it, and then processes it as though it were supplied to #pragma. so like, _Pragma("STDC CX_LIMITED_RANGE DEFAULT") is equivalent to #pragma STDC CX_LIMITED_RANGE DEFAULT
the standard also explicitly notes that this should work even if it's a result of macro replacement:
#define LISTING(x) PRAGMA(listing on #x) #define PRAGMA(x) _Pragma(#x)
LISTING(..\listing.dir)
fun fact, tcc doesn't handle this correctly. i'll try to write a patch which corrects that behavior in a bit. but anyways, how about this code?:
my understanding of the spec is that this should be allowed. as per 6.10.4.4p3: "The resulting completely macro-replaced preprocessing token sequence is not processed as a preprocessing directive even if it resembles one, but all pragma unary operator expressions within it are then processed as specified in 6.10.10 below." it's still a bit ambiguous, since translation phase 4 implies that macro expansion and Pragma execution happen at the same time, but clearly this isn't possible; they have to be sequenced one way or another. gcc agrees with my interpretation, allowing this without any warning (except for warning about how it doesn't support the pragma, because why would gcc support a standard pragma that would just be silly^). clang however, reports a syntax error! i initially thought this was a bug, but apparently it's intended behavior? https://github.com/llvm/llvm-project/commit/75f9681874252ac96db002a80df4202ec2cdd2f8#diff-718fc4606021bd56e5898cb6bed70b47b3a66f1bc680f8fa35ae9d60e8e2ed93R163. tbh i still don't really understand why the pragma's form needs to be checked at all until right before it's executed, but ¯(ツ)_/¯
^: i'm not even blaming gcc for this tbh. when the most prominent c implementation doesn't support a "standard" feature, then it's the standard that's incorrect, not the implementation. as far as i'm aware clang doesn't support standard pragmas either, so this isn't even just a gcc thing
the entire reason i've been finding these differences is that, in hare-c, in addition to running the check tests through c::check, i also run them through gcc and clang, to verify that, if they're passing, they actually, like, should be passing. and vice versa: if they're failing c::check, but also failing gcc and clang, then there's no bug, and the tests are wrong. but there's already quite a few places where i need to check whether GNUC and/or clang are defined, and selectively enable/disable certain tests accordingly. speaking of which did you know there's no way to check if the compiler is gcc with the pre-processor? the thing is gcc defines GNUC, but for compatibility, clang also defines GNUC, and i have to assume other implementations which support some gnu extensions also define it
@sebastian Also shouldn't something like #ifdef defined(__GNUC__) && !defined(__clang__) && !defined(__ICC) work to detect gcc? __ICC being Intel C Compiler, not that I care much about it but https://github.com/cpredef/predef/blob/master/Compilers.md mentioned it as also defining the GCC macros.
tl;dr: you can use consts that are set to true or false by build tags, and then 'if doMyDebug { .... }' for ifdef; Go's dead code elimination will remove things in the always-false case. There are limitations, though.
Sparked by @timbray although I suspect he's in an area that this general trick doesn't help much (for example, wanting to add debug-only fields to structs).
I would really REALLY like to have #ifdef in this Go code I’m working on - there’s this fairly heavyweight debugging stuff that I regularly switch in to chase a particular class of problems, but don’t want active in production code. #ifdef would have exactly the right semantics. Yeah, I know about tags.
Typically inline assembly is written in an #IFDEF block with a C/C++ alternative provided. Since the assembly is machine specific the devs need to write it for all the processor families they want to optimize for.
i'm pretty sure fortran is a collective hallucination, i keep seeing things about how it's frequently used and yet i have never seen fortran code or any supporting software in my life
Thomas Glexiner of Linutronix (now owned by Intel) has posted 58 patches for review into the Linux kernel, but they’re only the beginning! Most of the patches are just first steps at doing more major renovations into what he calls “decrapification”. He says:...
@psychicparrot42 Well it does involve quite some #ifdef BANANA as a matter of isolating/having alternative bits of code .. it also sometime involve to intentionally do something "wrong" to see if the code reacts "properly" to a "wrong" and/or crashes terribly ( via #ifdef BANANA ). It's a method where you start "simplifying to the bone" some complex code re-activating bits going from less to more complex until you understood how all works at least the point you need to make it work ( CONT )
sometimes you can just see the shadow of the #IFDEF that wasn't defined.
Every frame, Wheel of Fortune (and Jeopardy) checks to see if PackageAppInterface->bScreenCapRequested is set to true.
and if it is, a function is called, which turns it back off. And does nothing else.
True Story (lemmy.world)
FFmpeg's costly functions are all written in hand optimised assembly (twitter.com)
The temptation is always there (lemmy.world)
Thomas Gleixner aims for "decrapification" of Linux APIC code, longs for removing 32-bit code (lore.kernel.org)
Thomas Glexiner of Linutronix (now owned by Intel) has posted 58 patches for review into the Linux kernel, but they’re only the beginning! Most of the patches are just first steps at doing more major renovations into what he calls “decrapification”. He says:...