GNU bug report logs - #13949
24.3.50; `fill-paragraph' should not always put the buffer as modified

Previous Next

Full log

View this message in rfc822 format

From: "Petros Travioli" <travioli <at> gmx.de>
To: 13949 <at> debbugs.gnu.org
Subject: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy
Date: Mon, 28 Mar 2016 06:55:58 +0200

Some details on hashes. For eggheads.

Let's assume that you have never typed in some large number, say, 89434823472. And you have never seen it so far. And noone you know has ever seen this number. Neither have your colleagues, though you don't speak to them. On this empirical basis, you declare this number nonexistant for all practical purposes. Encountering this number in the future is less likely than the probability of finding oneself with those
two sweet blond ladies you've always wanted at your home in a horizontal position simultaneously. Since instead of the ladies, you have been accustomed to endure the society of your wife, well, you decide to use the value 89434823472 as an error value when, say, returning the file size.

Is it clever? Of course NO. There is absolutely nothing which precludes the next large file you see to have size exactly 89434823472. There is absolutely nothing which precludes the next two large files you see to have this size. As the time goes by, files get larger, so 89 GB files may be normal in a decade or so. (The ladies will never change their mind, though. Sigh.)

But that's exactly what happens when you are using hash functions to verify buffer equality, just with a more complicated mathematical formulation and at a slightly different scale.

So don't use hash functions to a two-sided correct answer to test buffer equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you are fine.

Petros

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.