diff options
author | Jim Meyering <meyering@redhat.com> | 2011-09-27 16:32:35 +0200 |
---|---|---|
committer | Jim Meyering <meyering@redhat.com> | 2011-09-27 16:49:51 +0200 |
commit | 57ee5493d996b69a02d367829d579729e8b20eaf (patch) | |
tree | d529aabd8f561ba816e3da9f2cef70078eec1eca /NEWS | |
parent | 1d0a7ed7d58cfcc2f44959fed431e7276bdf1d46 (diff) | |
download | coreutils-57ee5493d996b69a02d367829d579729e8b20eaf.tar.xz |
sort: avoid a NaN-induced infloop
These commands would fail to terminate:
yes -- -nan | head -156903 | sort -g > /dev/null
echo nan > F; sort -m -g F F
That can happen with any strtold implementation that includes
uninitialized data in its return value. The problem arises in the
mergefps function when bubble-sorting the two or more lines, each
from one of the input streams being merged: compare(a,b) returns 64,
yet compare(b,a) also returns a positive value. With a broken
comparison function like that, the bubble sort never terminates.
Why do the long-double bit strings corresponding to two identical
"nan" strings not compare equal? Because some parts of the result
are uninitialized and thus depend on the state of the stack.
For more details, see http://bugs.gnu.org/9612.
* src/sort.c (nan_compare): New function.
(general_numcompare): Use it rather than bare memcmp.
Reported by Aaron Denney in http://bugs.debian.org/642557.
* NEWS (Bug fixes): Mention it.
* tests/misc/sort-NaN-infloop: New file.
* tests/Makefile.am (TESTS): Add it.
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 4 |
1 files changed, 4 insertions, 0 deletions
@@ -2,6 +2,10 @@ GNU coreutils NEWS -*- outline -*- * Noteworthy changes in release ?.? (????-??-??) [?] +** Bug fixes + + sort -g no longer infloops for certain inputs containing NaNs + ** Improvements md5sum --check now supports the -r format from the corresponding BSD tool. |