 |
 |
> 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.