Aw c'mon. I'm being driven mad by plenty of other things. I don't need this.
Aw c'mon. I'm being driven mad by plenty of other things. I don't
need this.

Consider the following code:

	case 'O':
		output_filename = malloc(strlen(arg)+4);
		strcpy(output_filename, arg);
		strcat(output_filename, ".tmp");
		real_output_filename = arg;
		return;

The idea here is to malloc() a buffer big enough to hold the name of
a supplied file name, plus ".tmp". So we malloc() 'size of filename'
bytes plus 4, right? Wrong! ".tmp" is _FIVE_ bytes long! There's a
traling '\0' which strcat() gleefully tacks on _outside_ the bounds
of the buffer. Result: program corrupts own memory. Program SEGVs at
seemingly random times. Bill not like random SEGVs. Bill smash.

Know how I found this? I've been trying to bootstrap -current on my
2.1.0-RELEASE machine at work and I couldn't seem to get libc.a built
because the linker would intermittently blow chunks while executing
things like 'ld -O foo.o -X -r foo.o'. Since this is an initial
bootstrap version of ld, it was linked against the 2.1.0 libc, who's
malloc() behaves differently than that in -current.

Presumeably ld -O doesn't blow up in -current, otherwise someone would
have spotted this already. I don't know if this is a bug or a feature.

Anyway. I'm changing the strlen(arg)+4 to strlen(arg)+5. Bah.

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase