IRC channel logs
2025-04-09.log
back to list of logs
<oriansj>gtker: well M2-Planet doesn't have to support CONSTANT, it needs to include the // CONSTANT X86 3 where #define X86 3 lines exist <oriansj>so that cc_* can build the same code <oriansj>so having // just straight drop the lines is fine <oriansj>(and sadly why enum can't be used in M2-Planet) <matrix_bridge><gtker> Oriansj: We can't just drop the lines because we need it in bootstrap mode and it causes issues if we try to guard it with bootstrap mode since files are tokenized immediately after they appear on the cli <matrix_bridge><gtker> Oriansj, stikonas: Would it be possible to move all the emit_ related functionality in M2-Planet into a new file? It's getting a little spammy at the top of cc_core.c but I'm not sure how much it's going to break things for people who build M2-Planet <oriansj>gtker: well there are three ways we can fix that. Either require --bootstrap-mode to be the first option (if used), have an option pre-reader (like M2-Mesoplanet) or just queue up the files in a list and process them after the options have been read. <matrix_bridge><gtker> oriansj: Ah, that's why there's a prechecker in M2-Mesoplanet <matrix_bridge><gtker> It's true that there are easier ways around it, but from a top level view IMO it makes sense that the "cc_*" language doesn't have hidden traps like that, especially when the entire purpose is to make it easy to spot vulnerabilties <stikonas>well, if cc_* patch does not make assembly significantly more complicated, I don't mind fixing cc_* <stikonas>thoguh I'll be somewhat busy in the 2nd half of april and the beginning of May <matrix_bridge><gtker> stikonas: Cool. I might also take a look but I'll probably focus on M2-Planet <stikonas>but like I said, nothing till mid may from me...