<oriansj>looking at sloccount's output for mescc-tools-seed makes me happy <jelle>hmm I never uploaded mes to Arch <jelle>ah a configure failure might be related, I need to find some time to work on it again <vagrantc>my favorite line from the changelog: "Drop all patches, applied upstream." :) <vagrantc>jelle: i think there were 32-bit vs. 64-bit issues ... mostly mes is still targeting 32-bit ... from what i recall <vagrantc>jelle: and arch has some cross-compiler for 32-bit or something? <jelle>vagrantc: this time I got a "no limits.h" found <janneke>jelle: i'm sure you have found and looked at ./configure --verbose ***ng0_ is now known as ng0
***opal is now known as wowaname
***wowaname is now known as opal
<oriansj>and the first round of fuzzing hex2 and blood-elf have found a couple segfaults that are now cleared and catm now will detect if it isn't able to create an output file or read an input file <oriansj>pder: I'll be reviewing your pull request shortly (I just noticed it, wish you mentioned it here sooner) <pder>thanks, I was just trying to keep mescc-tools-seed up to date with the various changes going on in the submodules. <oriansj>pder: and I need all the help I can get ^_^ <pder>Great, well I just sent another pull request that is very similar. This time it updates mescc-tools and M2-Planet submodules and fixes the build scripts <oriansj>fossy: actually you might be able to merge those changes <oriansj>although you don't need to #include .c files to get gcc to compile kaem (if you look at the makefile) <oriansj>(as #including function implementations generally is a very very bad idea) <oriansj>what happens inside of a C compiler that has multiple files that #include a .c? <oriansj>well macro expansion simply copies in that code; now you have multiple functions with globals with the exact same names <oriansj>now if that compiler complies exactly with the C standard, it should be throwing a big red flag saying "Nope can't compile this crap" <oriansj>The problem is that Compilers like GCC and Clang do duplicate code elimination optimizations; that hide that error <oriansj>Hence traditionally only .h files are EVER #include'd and it was assumed only function prototypes and globals are put in them <oriansj>also note on limited machines, people traditionally did cc -c source.c -o source.o for all of the files being used and just cc *.o -o program to combine the result into a production binary. <oriansj>This was to reduce compile time to just the source files that changed and if you #include'd actual functions, it would have to recompile them; even if they didn't change. Where as if you just #include'd a .h which just had prototypes; no wasted work would be performed. <oriansj>make of course is able to figure out if a source file is newer than the .o that corresponds with it and recompile that source file; significantly reducing the compute requirements to compile and test an in development application. <oriansj>Those old guys, despite not having anything to learn from but their own mistakes, were really bright and minus a handful of bad trade-offs were generally headed in the right direction. <oriansj>Hagfish: if one wanted to get started on static code checking for mescc-tools, M2-Planet or mes-m2; splint is readily available for checking C files. Running something like: splint functions/match.c functions/in_set.c functions/numerate_number.c functions/file_print.c functions/number_pack.c functions/string.c functions/require.c cc_reader.c cc_strings.c cc_types.c cc_core.c cc.c cc.h gcc_req.h | less would point out alot of existing