Keith M Wesolowski wrote: > On Thu, Mar 15, 2007 at 11:10:32AM +0100, Roland Mainz wrote: [snip] > > It depends on how you define "sufficient way to test". I was often > > thinking about writing a OS/Net tree-wide patch for that... but I think > > this would be wasted work as long as we have to match the "requirement" > > that such a patch must be tested with all possible/imaginable codepaths > > (which is impossible for a single engineer (and even more difficult > > since I lack Sun's test suites) ... and I wish the barrier could be > > lowered to "... must result in a booting and running OS/Net which can be > > used for OS/Net development without problems... " - that would be a goal > > which we could archive quickly) ... ;-( > > I'm pretty sure we've been down this road before. > That's not a high enough standard.
AFAIK the previous "standard" was AFAIK that we _must_ gurantee that we have found&&eliminated all problems before we can do a putback - which is impossible for obvious reasons (how should we find all bugs in such a large codebase ? AFAIK not even the switch from Sun Studio 10 to Studio 11 had to match such a "quality standard" (uhm... and I could complain that some things are still broken since that switch... ;-( )). AFAIK we need a "high enougth standard" which we can reach - for example the same level which is used when the compiler gets updated between minor versions (for example Forte 6U1--->6U2). > A full PIT run is closer but I'd really prefer to > see an approach that looks for source or binaries with likely problems > and focuses testing on those. We were finding writes into string > constants fairly late in the gcc effort and I have little confidence > that we really got them all. Neither do I have the confidence that the gcc work caught all problems. But somehow we need a way to start this work, right ? > > ... and as I said... the real problem is that Sun Workshop/Forte/Studio > > defaults to writeable string literals - this issue needs to be addressed > > ASAP... > > If we had a time machine, that would obviously be the right thing to > do. Sort of like the 256-fd limit. But you're welcome to suggest it > to them; they make Major releases and often break stuff like this that > we then have to go work around. My idea was not about "breaking" things - I only want compiler "defaults" which matches how the ANSI/ISO C standard and most of the code was written. And I even suggested a backwards-compatibilty way (e.g. "-xstrnoconst") to make sure that we don't screw-up customers like gcc4.x did. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
