Comment by ~lattis on ~lattis/muon
1-2.) Fixed, thanks!
3.) Using
/
is equivalent to calling join_paths(), so this is just a stylistic thing. I prefer using/
.4.) This is for compatibility with older meson versions. ExternalProgram.full_path() was only added in 0.55.0.
REPORTED
RESOLVED FIXEDComment by ~lattis on ~lattis/muon
Maybe strtol with an errno check should be added to src/lang/string.c?
Comment by ~lattis on ~lattis/muon
REPORTED
RESOLVED FIXEDComment by ~lattis on ~lattis/muon
REPORTED
RESOLVED FIXEDComment by ~lattis on ~lattis/muon
REPORTED
RESOLVED FIXEDComment by ~lattis on ~mcf/cproc
The code where I encountered this had the
return;
wrapped in a#ifdef
so that the function became a noop under certain conditions.
Ticket created by ~lattis on ~mcf/cproc
The following code causes a segfault
void foo(int n) { return; switch (n) { case 0: break; } }
$ cproc -o test.o -c test.c cproc: compile: process signaled: Segmentation fault cproc: codegen: process 24579 exited with status 1 cproc: assemble: process signaled: Terminated $ valgrind --trace-children=yes cproc -o test.o -c test.c ... ==24591== Invalid read of size 4 ==24591== at 0x11E12F: emitvalue (qbe.c:1031) ==24591== by 0x11E720: emitinst (qbe.c:1139) ==24591== by 0x11ED14: emitfunc (qbe.c:1254) ==24591== by 0x10E2FF: decl (decl.c:1001) ==24591== by 0x1144BD: main (main.c:60) ==24591== Address 0x0 is not stack'd, malloc'd or (recently) free'd
Comment by ~lattis on ~mcf/cproc
In muon's case, this bug is surfaced by code like:
const struct { int a[1]; } b[1]; return b[0].a[0];
Another workaround is to remove
const
.
Comment by ~lattis on ~lattis/muon
Well, really the ninja program should be detected earlier in setup using find_program(), which I'm assuming abstracts away from the extension problem. I suppose I'd accept a patch with what you are suggesting as a temporary fix though.