[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sort -R: a more-conservative approach
From: |
Bob Proulx |
Subject: |
Re: sort -R: a more-conservative approach |
Date: |
Mon, 12 Dec 2005 21:35:24 -0700 |
User-agent: |
Mutt/1.5.9i |
Frederik Eaton wrote:
> Well, I guess it's only a factor of two, but there's a difference
> between bugs that cause a segfault in a tool that many people use, and
> bugs that might cause a new feature with 0 existing users to not be
> 100% cryptographically secure. That's just my two cents though
Your statement does not quite parse as I read it.
Sort is definitely a tool that many people use. So agreed that
introducing bugs in a tool that many people use is a bad thing. Also
agreed that this is a new feature and as such there are no previous
users and so pushing the inclusion of the feature out for a while
won't affect any existing users. So that is safe. Of what good is a
new feature that core dumps when run? If a segmentation fault is
being triggered then it is a bug and adding the feature would be
adding a bug too. That's bad.
If you are saying that since it only core dumps on 64-bit hardware
then I can only think that marginalizes everyone who uses 64-bit
hardware. Such as myself since my normal equipment is a 64-bit
system. But that does not change the fact that it also adds a bug
because programs should never segfault.
Bob