----- Original Message -----
From: "Phillip Helbig" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, November 30, 2000 5:22 PM
Subject: Re: Suspected bugs...
> > and Phillip replied:
> >
> > > I don't think it is too much to ask. At least some vendors have this
> > > list which Clive wants: it's in the release notes for the next version
> > > of the compiler, which detail, among other things, which problems were
> > > fixed since the last compiler.
> >
> > Then, I think, you didn't read what Clive wrote:
> >
> > "Many times when I have taken the time to submit a full bug report I
> > have
> > found that all that effort has been wasted, as the vendor simply replies
> > saying "we already know all about that bug, you can get the fix
> > here..."."
>
> As I pointed out, if he's using an older version he might find what he
> wants in the release notes of the newer version, or, as I suggested
> (don't know if this is available) the vendor could make some "running
> total" list of fixes which later show up in the release notes---this
> obviously exists as an internal list.
>
> > He wants a facility to enable him to determine *beforehand* whether a
> > certain bug report is superfluous.
>
> Right.
>
> No-one is talking about an EXHAUSTIVE list (that's probably impossible).
> Assume such a release-notes type list exists. Normally, one changes the
> code in steps and recompiles after each step. :-| If I see a problem,
> I know what I have changed. (And on VMS I have all the old versions; I
> don't see how one can do productive software development without such a
> system!) Suppose it has something to do with a defined assignment
> involving a user-defined type containing pointers to arrays. I can then
> search this list for these "key words" and see if I see something which
> might be my bug.
>
|