<stikonas>hmm, well I don't really have strong preference <oriansj>I'm just setting up the basics and feel free to change the names to suit you <stikonas>if you think more verbose is better, let's go with that <oriansj>and easier for people doing an audit to look at and guess correctly <stikonas>and spawned utilities are taken from PATH? <stikonas>possibly with some env variable overrides... <stikonas>hmm, before full kaem is built, stage0-posix can't easily use env-variables <stikonas>but we can just be explicit up to that point <oriansj>stikonas: true but M2-Mesoplanet can be done after kaem but before mescc-tools-extra <stikonas>it will still make building mescc-tools and -extra much easier <stikonas>well, we can build M2-Mesoplanet eariler, just wouldn't rely on auto-spawning <oriansj>wife interrupt indicates dinner. Will resume after; happy hacking <stikonas>pushed WIP branch macro_functions for M2-Mesoplanet <stikonas>will need more changes (whitespace processing) before we can merge it <oriansj>stikonas: and I have a stupid idea to hack the preprocessed output so that M2-Planet still produces useful line error numbers <oriansj>cc_reader can use \x7F as a single character flag to reset the line number and change the filename we use when building the tokens <oriansj>and as it is the DEL character, it shouldn't ever be in human written input anyway <oriansj>I'll be working on the spawn bit in cc.c so it doesn't impact your work in cc_macro.c <oriansj>Unless you want me to hack together basic #include support so you can avoid any possible merge conflicts <stikonas[m]>Del might work. Or alternatively, have line info in auto generated comments and strip them in m2-planet <stikonas[m]>Either spawning or include shouldn't cause conflicts for me <oriansj>well I could also do // FILENAME foo.c much like // CONSTANT foo 4 we have now <oriansj>might require more complexity in M2-Planet's cc_reader.c but I'll look into that later <oriansj>I guess I'm going to have to add a couple syscalls in M2libc to support proper tempfiles <oriansj>and of course risc-v doesn't have unlink <oriansj>prototype for unlink and remove are up <oriansj>now to figure out the correct way to deal with mkstemp <oriansj>as it is supposed to be: unistd.h for legacy systems but stdlib.h per IEEE Std 1003.1, 2004 but it is just a naked syscall <oriansj>why not the way it was likely done by most libcs; make unistd.h have a int _mkstemp(char *template); and put a mkstemp stub function that calls _mkstemp ***jackhill is now known as KM4MBG
<oriansj>hmmm we might have to tweak M2libc when we get into doing #includes <oriansj>now to figure out the magic number for O_EXCL ***KM4MBG is now known as jackhill
<oriansj>a prototype for mkstemp using the tempname bacon for the function <oriansj>the standards body should have made it part of stdio.h instead of stdlib.h <stikonas[m]>yeah, it looks like mkstemp doesn't need any syscalls. Hmm, and strangely, meslibc does not implement it either <oriansj>and O_EXCL isn't even used outside its #define in mes <oriansj>ok, it appears mes just changes the suffix of the input files and overwrites anyfile that might have that name <oriansj>you can find it real quick by looking for M1->blood-elf in module/mescc/mescc.scm <stikonas[m]>I guess either way will work (tempfiles or overwriting files with changed suffix) <oriansj>well tempfiles is the way least likely to accidentially destroy someone else's work <oriansj>but oh well; I've got that all sorted and will get back to hacking on the spawn logic (which is kinda ugly but I'll get it done) <oriansj>probably best to set a fuzzing mode flag when dealing with exec as that is kinda dangerous as fuck <stikonas>yeah, we don't want running random executables... <oriansj>hmm what the heck is the standard C way of going from the int file handle to a proper C FILE* object? <oriansj>might have to add that to M2libc then <stikonas>well, probably functions needed to build mes should also be moved to m2libc...