IRC channel logs

<mwette>I'll need to update the grammar in c99/mach.scm

<aggi>sigh. long long, floats

<aggi>it's interesting this didn't affect the proceeding with a tcc-compiled kexec-fiwix

<mwette>ekaitz: I have the attribute fix in, I ran into another cpp bug.

<aggi>notable patching necessary

<aggi>another dis-advantage with rebasing for tcc-head, even when this works with pnut then (which it doesn't yet)

<aggi>all this requires confirmation for mes-cc too

<aggi>besides further long long and float related issues it is non-trivial preprocessor magic which piled up on tcc-head too

<aggi>i'll postpone this for a moment and keep the pnut|mes-cc -> tcc-0.9.26 -> tcc-head chain

<aggi>it's a little saddening tinycc-devel didn't listen to janneke to avoid at least some of the breaking changes

<matrix_bridge><cosinusoidally> tcc mob could also suffer from software supply chain issues. Anyone on the internet can commit to mob, so anyone could push malicious code. Plus with tcc's current development model it could be months before anyone even noticed.

<matrix_bridge><cosinusoidally> I remember a couple of years back I pulled a version of mob that would miscompile gnu make. I spent ages bisecting, and it turned out the issue had been introduced many months before. I tried again a few months later and it worked fine. I'm sure these types of regressions slip in all the time.

<matrix_bridge><cosinusoidally> I can't remember why I didn't post a bug report to the mailing list at the time (and even if I did it would have been luck of the draw whether it got fixed) but a decent regression test suite building real world codebases would have likely caught it immediately.

<matrix_bridge><cosinusoidally> Which is probably why people use a snapshot of some revision of tcc and then stabilise that.

<aggi>i think there's a few competent developers who keep an eagles eye on what is pushed to mob

<matrix_bridge><cosinusoidally> yep, and there's the test suite, but competent developers still miss things if they don't have a comprehensive test suite. As it currently stands it's difficult to answer the question "is mob in a good state". tbh I'd gladly take a "grischka" branch or a "Herman ten Brugge" branch that were always in a known working state.

<nikolar>what's mob

<aggi>i'll proceed with the tinycc/os bootstrap, intended for nightly-builds of this

<aggi>the live-bootstrap platform is almost perfect for this, to integrate a few steps/ on demand to reproduce issues

<aggi>i'll keep shut up for a while and get this done

<aleksi>nikolar: mob is the main branch of tinycc, to which anybody can push at any time

<nikolar>oh yea that's why it sounded familiar

<matrix_bridge><cosinusoidally> and mob is also the branch that all users are expected to use. Which I think is bad from an end user perspective as you never can really know if mob is in a good state (or even whether it includes malware or something). Every few months or so grischka (who is nominally the maintainer) will appear and review the commits eg...

<matrix_bridge>... https://github.com/TinyCC/tinycc/commit/5ec0e6f84b47ebd8c269b581712666313f5edaef . grischka commit will often also include other changes he has made. That how it works at the moment. Essentially a code drop every few months. If someone wanted to cut a release the best they could probably do is wait for one of grischka big commits, watch the mailing list for follow up bug fixes, cut from that, revert any...

<matrix_bridge>... non-bugfix commits, test and then ship that.

<nikolar>oh that's a weird approach

<mwette>found another cpp bug, ran into another one

<mwette>mes: try nyacc-3.04.3 : I am able to parse a number of tinycc files now

<aleksi>Thanks mwette, 3.04.3 fixed a crash I was having with empty/zero macro arguments

<aleksi>Could you check the file arm64-tok.h from my patch that I've submitted on the tinycc-devel mailing list? https://lists.nongnu.org/archive/html/tinycc-devel/2026-02/msg00008.html I'm seeing 'bad suffix on number: "8B"' from nyacc

<aleksi>I think it's related to the line "DEF_ASM_VEC_REGS(8B)"

<stikonas>hmm, now I get

<stikonas> +> /usr/bin/mes-m2 --no-auto-compile -e main /usr/bin/mescc.scm -- -S -o tcc.s -I /usr/include/mes -D BOOTSTRAP=1 -D HAVE_LONG_LONG=0 -I . -D TCC_TARGET_I386=1 -D inline= -D CONFIG_TCCDIR="/usr/lib/mes/tcc" -D CONFIG_SYSROOT="/" -D CONFIG_TCC_CRTPREFIX="/usr/lib/mes" -D CONFIG_TCC_ELFINTERP="/mes/loader" -D CONFIG_TCC_SYSINCLUDEPATHS="/usr/include/mes" -D TCC_LIBGCC="/usr/lib/mes/libc.a" -D CONFIG_TCC_LIBTCC1_MES=0 -D

<stikonas>CONFIG_TCCBOOT=1 -D CONFIG_TCC_STATIC=1 -D CONFIG_USE_LIBGCC=1 -D TCC_VERSION="0.9.26" -D ONE_SOURCE=1 tcc.c

<stikonas> ***MES C LIB*** fdungetc ungetc buffer overflow fd=136

<stikonas>strange though, this sounds like mes-m2 issue and not related to nyacc

<stikonas>and yet it was working with older nyacc

IRC channel logs

2026-03-13.log