Re: strings should be dumb

[Greg Alexander <bugreg at galexander dot org>]

This is what makes strings bad:

Nicholas Clifton wrote:
> The GNU projects are about enablement, not restrictions.  Sometimes this
> does encourage feature creep

This is also what makes strings bad:

Mike Frysinger wrote:
> it's full of range issues like this (by nature of its job), and will
> continue to be so.  unless we switch to a language like python where
> exceeding memory ranges is guaranteed to not access invalid memory (not
> that i'm suggesting that).

A commitment to feature creep is paired with an acceptance that no C
programmer is capable of checking bounds.

Feature creep is wrong.  Accepting patches from C programmers who have
not had their potty training is wrong.  When they combine, the two
failures feed on eachother.

Python is not the answer, a passing interest in excellence is.  There are
C programmers who do not shit where they eat.

I can't submit a patch for these cultural problems.  I know in the ivory
tower of FSF mailing lists you get pretty detached from the real world,
but there is no moat so I will remind you that your adherence to a
culture of suck is both voluntary and exceptional.

And further, there's no point in a real C programmer getting involved in
libbfd so long as these two policies remain.  As long as you will accept
feature creep patches from any old mouthbreather, there will be bugs in
libbfd.  That's not C's fault, it's yours.

Cheers,
- Greg

On Thu, Oct 30, 2014 at 10:25:29AM +0000, Nicholas Clifton wrote:
> Hi Greg,
> 
> >It has come to my attention that strings is smart.  strings should be
> >dumb.  The default behavior should be changed to the behavior when -a is
> >specified today.  The datasection_only behavior should be eliminated
> >entirely.  strings should not link against bfd.
> 
> Sorry but no.  If you want a dumb strings program then use "od -S 4". If you
> want a strings that is not linked against the bfd library then use
> eu-strings.  If neither of these options appeal then write your own program.
> 
> Alternatively help us make strings better.  If there are security holes then
> please report them on the mailing list or the bugzilla system. (Note -
> several security holes have been fixed in the last few days...)  If you want
> a strings program that defaults to a dumb behaviour then create a
> configure-time patch that enables this and submit it for review.
> 
> The GNU projects are about enablement, not restrictions.  Sometimes this
> does encourage feature creep, and sometimes forks are created with this
> specific goal of reducing bloat.  But as far as I am concerned, for now the
> GNU Binutils are good, and they do not need dumbing down.
> 
> Cheers
>   Nick
> 
> 
> 
> 
Feature creep is wrong.  Accepting patches from C programmers who have not had their potty training is bad.  When they combine, you are going to have epic failfest.