"cmp" mistakes /dev/stdout for /dev/null

[ttcoder]

hrev49623 (didn't check in older hrevs yet)

Unzip the attached folder. Do the below and watch as cmp fails to find a difference, even though there's one as evidenced by cksum and md5sum:

/boot/system/cache/tmp/New folder/cmp_bug> ls
runtime_loader49137  runtime_loader49623
/boot/system/cache/tmp/New folder/cmp_bug> cmp *
/boot/system/cache/tmp/New folder/cmp_bug> cksum *
3624641877 154316 runtime_loader49137
3137876803 154316 runtime_loader49623

Pretty jaw dropping when I saw that, not used to seeing binutils fail completely :-o ...

[ttcoder]

Bug is reproducible with e.g. these 2 files

[ttcoder]

Rebooted into an old hrev I have lying around, and things work normally there:

~/Desktop/cmp_bug> cmp *
runtime_loader49137 runtime_loader49623 differ: char 25, line 1
~/Desktop/cmp_bug> cksum *
3624641877 154316 runtime_loader49137
3137876803 154316 runtime_loader49623
~/Desktop/cmp_bug> uname -a
Haiku shredder 1 hrev45943 Aug  2 2013 00:35:45 BePC Haiku

[jessicah]

It appears the issue is with the output (or lack thereof). The exit code behaves normally. E.g. echo $? after the command will output 1 if they differ, 0 if they're the same.

Anyway, this is part of the diffutils package at HaikuPorts now.

[korli]

This isn't exactly a bug in cmp, more in Haiku: to find out if the output is redirected to /dev/null, cmp probes whether the stat structure are somehow identical. The two file descriptors are character devices and have st_rdev set to -1. If cmp finds out stdout is /dev/null, then it spares the job of computing diffs, and outputs nothing.

Filling st_rdev for character and block devices would effectively fix this bug.

[ttcoder]

Tentatively closing the ticket I had opened over at HP (​https://github.com/haikuports/haikuports/issues/312) and re-opening this one

I wonder when this regression, mis-detection of stdout, occured though. E.g. hrev49630 should affect only Tracker-launched executables, but did those executables launched from a Terminal see a change in their 'environment' too, in the recent months

[pulkomandy]

It may be that we moved coreutils to a separate package and updated them at the same time. So, the underlying bug was probably already there, but our previous cmp version didn't trigger it.

[pulkomandy]

Fixed in hrev49675.