On Fri, 2011-02-18 at 19:01 -0700, James McKenzie wrote: > On 2/18/11 4:00 PM, Joe Zeff wrote: > > On 02/18/2011 02:44 PM, Ian Malone wrote: > >> Used properly, yes you've avoided buffer overruns, used badly no. > >> strncpy(dest,src,strlen(src)+1) > >> Ridiculous? Yes. Never used in practice? I'd like to believe it. > >> strncpy has been in C since it was first standardised, but people > >> still write code that overflows. > > This is what code review is for. > +1. I used to get paid to do this and you would not believe the coding > mistakes I found. > > James McKenzie On the other hand, if reviewed code is reviewed a second time, in most cases other errors show up. And coding errors are not the sole issue. Logic errors, later edits, production modifications, and support editing also contribute their share. Even Object Orientation won't relieve all problems. I recently looked at a program where an object pointer was set to null in initialization, but later code would try to open a file that the pointer supposedly referenced, with no check for the null. This is a logic error, but could be just as devastating to the system, but would not be found by most code reviews. Moreover I often see object orientation espoused as a cure for these ills, but it is not. If you open up a "mature" C++ program and review the objects used, and really dig into their use i.e. trace the later defined objects, you can often find objects with what I would call stale code, that is functions that are not used in most cases in the dependent objects, and in some cases not even used in the original object any longer. There are probably tools that can detect these things, but I am not a proficient C++ coder, so I have not worked on using or developing support tools for that environment. But stale code offers opportunities for system penetration that do not otherwise exist. And since the use of pointers is still prevalent in code, misuse of pointers is definitely an abuse point. In short, programmers are fallible, and can make mistakes. Most such mistakes are small and have few if any consequences. Some are more problematic, and many are caught in alpha and beta test, or code review. But there is no panacea. We are all only human, and our code is the frail product of a human mind and human processes. When code is used in "mission critical" or "life support" applications, then every tool at our command should be used to verify that code, and even then mistakes will get through. That's life. Regards, Les H -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
