Strange pipe behavior

[gavinfielder]

s_null_space_padded_field_width_lj was seen by smaddox returning 35 return value in fork mode but 32 return value in non-fork mode. The value should be 32 but somehow the data being sent in the pipe is modified or incorrectly read. Correct implementations should always have the same number being returned, but 35 is incorrect reporting for "expected return value" in this case. Probably with other cases as well.

[gavinfielder]

d27c8f7 Re-enabled fork mode by default so that people have access to most features still, but added warning when logging test results in fork mode

[gavinfielder]

Issue exists on ubuntu machine as well. Probably not machine-dependent after all.

[nkone]

Test 65: s_null_space_padded_field_width_lj [PASS] Last passed 9 min ago
I ran the test with ./test -x (fork mode on)

[gavinfielder]

Test 65: s_null_space_padded_field_width_lj [PASS] Last passed 9 min ago
I ran the test with ./test -x (fork mode on)

Eric: yeah, this bug doesn't affect whether a test passes or fails, it only changes the data that gets printed to results.txt as to what the return value was and should have been--it changes both the expected and the actual in the same way, but in a way that I haven't been able to determine yet. My latest commits make it such that the return values don't get printed at all when IGNORE_RETURN_VALUE=1, and I've made IGNORE_RETURN_VALUE=1 the default behavior for now, so now most users won't encounter the bug at all. I'm still trying to figure out what it is and how to fix it.