> I suspect this will be easy to fix once we know which > case (size/alignment) is causing it. > > IMHO we should probably keep strcpy()'s behavior the > same in this undefined case. > It seems likely there is more code out there that > expects the old behavior.
It may be prudent to avoid changing "undefined" behavior in cases where it's known that a lot of code incorrectly depends on it. But I think it would be at least as prudent to obtain and apply tools to identify the offending usage and fix it. Otherwise, one is simply covering up errors; understandable for maintaining binary compatibility, but horrible for improving quality. Reminds me of AT&T SVR[23] on the 3B15, where behavior like /usr/lib/0...@0.so.1 provides was the default; that let a lot of bad code keep running, but the result is that the bad code didn't get fixed until ported to some system where that was not the default behavior. While some degree of backwards binary compatibility with bad behavior of other people's code may be justified, IMO it's never justified to leave such behavior in code one has control over oneself. http://valgrind.org/docs/manual/mc-manual.html#mc-manual.overlap seems to say that the memcheck component of valgrind can catch this. But AFAIK, valgrind still hasn't been ported to Solaris. And I gather it's a runtime thing; I wonder if there are any static analysis tools that can find this sort of problem by examining the code rather than by monitoring execution. Is there some tool (preferably free) that can run on (Open)Solaris and identify instances of overlapping copies with functions where that is undefined? Could this be done at runtime with creative use of DTrace for instance (would be cool insofar as it could potentially catch it across a whole bunch of processes on a system). Or I suppose one could write an LD_PRELOADable set of wrappers around all the copying functions where overlapping copy is undefined, that would check for and report it. But with either DTrace or wrappers, I imagine it would be pretty difficult to relate that back to the source code... -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
