IRC channel logs
2025-05-16.log
back to list of logs
<euouae>I'm writing an m4 clone in Python and there's someone who wished it'd be lower in the bootstrap hierarchy. I'm wondering if anyone here thinks it's a good idea to try and implement it in GNU Mes? <deesix>M2-Planet has some pointer arithmetic support since 1.12 I think, given that a227f2cb185b57ea1f8dfc8f0c7d502af9b136f7 seems to be part of that release. The merge commit talks about """`+=`, `-=`, `+`, and `-`""" but here on IRC I read it's only about `+=` and `-=`, right? The CHANGELOG.org is AFAICT surprisingly quiet about this important change (which creates backward incompatibility). I'm a bit <deesix>confused... Is just the merge message wrong? What's the "policy" for incompatible changes? No major version bump? <deesix>(mostly rhetoric questions, but I'm really hoping the changelog will get some note about the change) <deesix>(maybe a note on the 1.12 section... and a note on the section on the next release, about the former note) <nikolar>how's adding pointer arithmetic a breaking change? <deesix>Because there's code using the older behavior. <deesix>The message mentions one such example, a7b40ff870c37f8d726d2ed8d9e4f5ad3a51b882 <nikolar>i mean that code was using borked arithmetic <nikolar>it's not something to be emulated in your code <deesix>The code was using what was available (from M2-Planet) for it; workarounds for sure, but those are affected nonetheless. <deesix>nikolar, let me know if you want a more concrete picture of the situation; not sure if I'm explaining it well enough. <nikolar>What I'm saying is, the code that was m2libc was already booked <deesix>The point is the "borked" code had no other way of doing some operations, because M2-Planet did not provide pointer arithmetic (so the code is written taking the known missing feature into account); and that code needs to be compiled by M2-Planet. <deesix>Now that the feature is not missing, the arithmetic changes. <deesix>(so the workaround needs to be removed... hence breaking change) <deesix>For example, regular C (and new M2-Planet) is just `p += 42` (p being a pointer). But programs have workarounds like `p += 42 * sizeof(<type_of_p>)`. <matrix_bridge><Andrius Štikonas> deesix: do we have actual examples of such programs? <matrix_bridge><Andrius Štikonas> mescc-tools and mescc-tools-extra were fixed <matrix_bridge><Andrius Štikonas> mes didn't use += anywhere with pointer arithmetic... <matrix_bridge><Andrius Štikonas> We are making more incompatible changes in the next release too but all gets closer to C <deesix>I have patches to mes that are affected; in any case... the main problem I'm trying to make is lack of documentation about the breaking change. <deesix>... and conflicting information about it, adding to the confusion. <deesix>We don't know if there're more programs out there. <matrix_bridge><Andrius Štikonas> Though it doesn't explicitly talk about pointers <matrix_bridge><Andrius Štikonas> There wouldn't be old hacks relying on bad behaviour of ++ <deesix>I'm looking at M2-Planet's CHANGELOG.org. <matrix_bridge><Andrius Štikonas> Well, add more explicit note there I guess <deesix>(and, for reference, the commits I referenced are also from M2-Planet repo) <deesix>I'm not saying the info was not there on purpose (forgotten is fine, it happens). <deesix>The merge message is really misleading, in any case (again, it happens, sure). <matrix_bridge><Andrius Štikonas> I think because originally gtker tried to add both for + and - too <matrix_bridge><Andrius Štikonas> But then there we too many edge cases and too hard with current M2-planet architecture <matrix_bridge><Andrius Štikonas> Aldo for mes it generally gets incompatible after any more significant codegen change <matrix_bridge><Andrius Štikonas> As we need to update M1 defines in mes repo