Re: HEADS-UP: /bin/sh memory management bug fixes committed

["Thomas Mueller" <mueller6725%twc.com@localhost>]

from Robert Elz:

> I have just committed the (long awaited) bug fix set for /bin/sh --
> to fix some bugs I introduced recently - but also, several old,
> devious, bugs that had remained hidden for years, but which became
> more exposed with some of the recent changes - not so much the changes
> themselves, but with the way the code changed to accommodate easier
> debugging of the changes.

> So please watch for anything that looks like it could be shell misbehaviour,
> and either let me know, or file a PR.
        
> You might also want to consider rebuilding anything that has been built from
> a shell script (particularly a large one - like a configure script) in the
> past couple of weeks.   While it is very unlikely that a bug could have
> caused the script to fail in a way that would not be immediately obvious,
> with some of what has been fixed, almost anything is possible.  Note it is
> not so much the complexity of the script that matters, but the amount of
> data processed (strings expanded, ...) which would trigger problems, so a
> small script that collects, massages, then outputs, a lot of variable
> length (but probably normally lengthy) data is far more likely to have been
> affected than a huge set of functions that work on a relatively small data set.

I guess bugs in sh could affect a run with pkg_rolling-replace and other updates using pkgsrc?

I suppose strange things can happen?

Am I advised to rebuild my system (i386 and amd64) using build.sh after "cvs up -dP -A"?

I will still have the dubious /bin/sh from just this past week.

Or should I rebuild twice, the second time being with the new /bin/sh, or is that overkill?

Tom