On Wed, 13 Jun 2012 16:36:32 +0200 Dan Shelton wrote:
> On 13 June 2012 15:43, Glenn Fowler <[email protected]> wrote:
> > we've stated our case
> > I'll restate one more time
> > I guess we have a larger than average (internal not-open-source) user base
> > to deal with
> > a lot of ksh usage within that user base is on critical paths
> > any disruptions obviously cause delays, but it can also damage ksh's rep
> > and make it harder for us to convince projects to use our stuff
> > many times ksh and the standard (1) commands are a foot in the door
> > to other software that we first peddle internally, and then externally
> OK. I understand your point. But: Did you realize that some of us have
> carefully formulated proposals to put grep, od, tr and xargs into
> libcmd but NOT enable them by default, that means a intentional
> builtin grep, builtin od, bulitin tr or builtin xargs must be issued
> before ANY damage may occur? This will limit the possible damage down
> to the explicit users who explicitly ask for this trouble.
dgk had discussed these issues privately before they were proposed
I can't count how many times a simple change has come back to bite us
(this includes linking in code that is not even used -- there are many
large legacy projects that make it very hard to remove code, even if it is
dead by 100 different ways of looking at it, because of unintended consequences)
we decided to err on the side of caution
especially where the integrity of ksh is involved
with the current solution all control is limited to the .paths file
when diagnosing problems we can say "remove the .paths file" and
be reasonably certain that -lcmdtst is out of scope
we also wanted to limit the number and types of ksh versions in the field
e.g., to avoid
"replace ksh YYYY-MM-DD immediately because there is a security bug in
xargs"
lets get ksh stability against the great debugging that has been going on in the
past few months (valgrind, bleeding edge gcc options, bleeding edge non-gcc
builds)
and separately, stability in -lcmdtst
and then revisit -lcmdtst::foo => -lcmd:foo
*separate* is key here
the ast code base has survived partly because it is composed of individual
components
that can be isolated and tested separately
this does not eliminate problems when they are composed
but it helps guide the debugging process towards api boundaries
things similar to this have progressed this way in the past:
(*) forumulate a possibly throw-away opt-in solution that does not affect
embedded scripts etc.
(*) evolve the regression tests to cover all problems encountered
(*) let the solution and tests soak through an official release or two
(*) finally, think about a more permanent opt-out solution and test that
the important part is that portability and regression test coverage must be
fairly complete
so that the proposed feature works the same on all target architectures
we are nowhere near complete for -lcmdtst and its components
I'm going to try really hard not to address this issue for a while ...
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
