IRC channel logs
2026-09-25.log
back to list of logs
<stikonas>but if you need 4, I think you should use uint32_t <ekaitz>i was nasty and I was trying to make that struct fit in a pointer size, but if the pointers depend on the platform <ekaitz>and the gc should know about that better <mwette>e.g., on x86_64 ints are typically 4 bytes, while pointers are 8; C says enums are ints <ekaitz>i put two ints inside of a pointer <ekaitz>but, when this thing is built for i686 it explodes <ekaitz>and for some reasons mes is built in 32 bits sometimes <mwette>well on 32-bit, ints are 32 and pointers are 32, typically, but long might not be <mwette>gcc -E -dM - </dev/null | grep SIZEOF_ <mwette>I see it now. enum: 4, 1st union: 8, 2nd union: 4 <ekaitz>and if the first union was 4, i could copy things around without any special change <ekaitz>mwette: no idea what this means right? <stdin>:1: parse failed at state 512, on input "unsigned" <ekaitz>it would be great if it at least gave me the file where this happens <mwette>That's probably in a cpp macro expand then. Did you add #:debug #t ? <mwette>There was a bug where I was missing some oddball decl's like "long unsigned int". <mwette>I don't know which nyacc/c99 version you are using. <mwette>Or are you using the nyacc-cp I gave mes? <ekaitz>i'm using whatever the guix.scm package gives mes, and it looks like it's 3.00 <mwette>(@ (nyacc version) *version*) in a program <ekaitz>oooh wow it's dumping a huge output <ekaitz>hmm hard to know where it fails honestly, even with the debug <mwette>(use-modules (nyacc lalr) (nyacc lang c99 mach)) (with-output-to-file "gram.txt" (lambda () (pp-lalr-grammar c99-spec) (pp-lalr-machine c99-mach))) <mwette>the second part of "gram.txt" will have a line that starts with "512:" . That's the state where the parse error is occurring. <ekaitz>I have a couple of very ugly gotos! <ekaitz>which btw M2 accepts but mescc doesn't <ekaitz>basically it doesn't let me jump to declarations <ekaitz>(even if they are also definitions) <ekaitz>i think mostly the issue comes from the `varuint:` label <mwette>janneke complained about that before: That non-standard C: a gnu extension. You can easily fix by putting { } around the code between `:' and, say, `break;' <ekaitz>(i found some more similar issues in the evaluator, too) <ekaitz>so changing this things made it better <ekaitz>i'll probably leave it for tomorrow <mwette>But you were having so much fun! <ekaitz>ACTION also has plans of writing his own C compiler in C but after seeing all this is regreting it <ekaitz>mwette: i tracked down a nyacc parse error to somewhere that I don't see why it sould fail <ekaitz><stdin>:1: parse failed at state 1, on input "b" <ekaitz>and I found where that is because before it was an "a" <ekaitz>there's a problematic include below but I tried to replace it with an #if and still fails with the same error <ekaitz>(or maybe it was just me because I was feeding the compiler that file alone) <ekaitz>it was that! thanks for the help! <ekaitz>mwette: you have been very helpful already :) <ekaitz>I was just feeding the compiler a few files that were designed to be included, and were not compilable on their own <ekaitz>just to share the good news, our new Mes core is able to run MesCC perfectly fine and compile itself <mwette>Does the core implement hash tables? <matrix_bridge><Jeremiah Orians> M1-macro implements a rather simple hash table. <mwette>The stripped down nyacc c parser (nyacc-cp) is much faster, mostly due to using hash table for cpp lookup. <matrix_bridge><Jeremiah Orians> ekaitz: The fun part of C compilers is the compiler part. The terrible part of C compilers is the macro expansion. Which honestly carries so very many sins. And why I wish for a single stand-alone C macro expansion program to supports the whole thing and has a well defined set of C tags (such as #FILENAME) that allows the simplified C compilers to report accurate line numbers for errors and not have... <xentrac>also a single stand-alone C macro expansion program predates the K&R book <xentrac>I mean, I'm not criticizing mcpp in any way, just thinking that sort of the whole point of the C preprocessor's design is so that it can be a preprocessor, which is to say, a stand-alone macro expansion program <xentrac>so it seems more like a thing to download and enjoy than a thing to wish for <matrix_bridge><Jeremiah Orians> Ok; from a quick glance at the source code. This uses a boatload of C features. <mwette>Right. IMO, if you want a minimal C, don't support function macros. <matrix_bridge><Jeremiah Orians> So converting it into the M2-Planet subset would definitely take some work <mwette>For down-the-line C, mcpp is probably trustworthy. <matrix_bridge><Jeremiah Orians> But at that point we would have TCC and GCC; which limits the bootstrap benefits. But with rework and massively reducing its bootstrapping requirements. We definitely could get it into that useful role. <ekaitz>i agree on the expansion part... :( <ekaitz>are you guys aware of this "dependable C" website and his author Eskil Steenberg? <ekaitz>I wanted to make a compiler for "just" that <matrix_bridge><Jeremiah Orians> Well reading it makes me think of it as less of “here are the primitives that you can depend upon” but more of “here is a list of things that you shouldn’t try to depend upon” <ekaitz>just out of curiosity: what bothers you from that subtlety? <matrix_bridge><Jeremiah Orians> A list of primitives can grow and the previous set keeps working. A list of prohibitions can always force a new set of rewrites <ekaitz>also it specifically mentions those things new standards made change meaning like `auto` <ekaitz>ACTION thinks the `auto` thing is a disaster <matrix_bridge><Jeremiah Orians> True but hence why I called out that it is not a list of dependable primitives but a list of prohibitions. <ekaitz>i mean most of it is: just use the old stuff without this and that <ekaitz>until they make `static` mean something else hehehe <matrix_bridge><Jeremiah Orians> But go back before the meaning of auto changed and imagine that the prohibition is not there. So you wrote code that contained auto. Thus the previously defined “dependable code” suddenly, no longer is. <matrix_bridge><Jeremiah Orians> Just because auto changed and the prohibition list updated accordingly. <ekaitz>the good thing is the guy is also in the C standards commitee so he can also fight in that area :) <matrix_bridge><Jeremiah Orians> Well, that is the thing. The M2-Planet C subset is effectively all of the C primitives that one should reliably be able to depend upon forever. <matrix_bridge><Jeremiah Orians> (Because pointer math isn’t really dependable) <ekaitz>this is a little bit like the ship of theseus in a sense <ekaitz>if you remove pointer arithmetic, is it still C? <matrix_bridge><Jeremiah Orians> With only the defect regarding short-circuit logic (which I contend shouldn’t actually be depended upon either) <matrix_bridge><Jeremiah Orians> well pointer arithmetic existed prior to arrays and structs. <matrix_bridge><Jeremiah Orians> But pointer arithmetic is prone to Undefined Behavior when it goes through optimization. <matrix_bridge><Jeremiah Orians> So my perspective is if you can’t express your data with structs and arrays; then you have not thought about your data long enough <matrix_bridge><Jeremiah Orians> It comes with the added benefit of you can avoid type casting <ekaitz>i don't fully agree but I kind of agree <matrix_bridge><Jeremiah Orians> Now granted; I wish C came with much stronger types out of the box (and made type promotion explicit rather than implicit) such that the question of “how many bits is an int” shouldn’t depend upon the host platform. <ekaitz>i do agree very much with that last sentence though <ekaitz>i have been bitten by it yesterday hehe <ekaitz>i guess C is a relic we kept for too long, and carries a huge history with it <matrix_bridge><Jeremiah Orians> Believe it or not cobol used to allow developers to define exactly how many digits are stored. They could write phone_number PIC9(10) VALUE 9998675309. To make a variable phone number that was 9 digits in base 10 <matrix_bridge><Jeremiah Orians> ADA kept that idea and extended it slightly <matrix_bridge><Jeremiah Orians> But none of the C replacements ever got the idea of bringing that idea back <ekaitz>isn't that the reason for the 2000 effect? <ekaitz>I don't know if a global panic is good advertisement for a feature <matrix_bridge><Jeremiah Orians> That definitely occurred in places but the most common Y2K bug was they didn’t cover the 400 year rule about leap years <matrix_bridge><Jeremiah Orians> And the smartest places only stored dates in their database and it was their database software that needed to be patched. (A fuckload of Oracle databases had that problem) <matrix_bridge><Jeremiah Orians> Speaking of which any places still using Oracle are going to hit a 2038 bug too <ekaitz>nobody gets fired for choosing Oracle <matrix_bridge><Jeremiah Orians> At the State of Michigan; those damn things are like STDs. I have been aggressively trying to replace them with SQLite and PostgreSQL. <mwette>Would you prefer a min-C that used, say, int32_t instead int, say, and required explist type casting. A rusty C. <mwette>Can C really exist w/o pointers? What if you want to pass a struct by reference? <roconnor>arguably SPARK is kinda like C without pointers.