On Tue, Nov 22, 2005 at 09:42:49PM +1100, O Plameras wrote: > Andrew Bennetts wrote: > >On Tue, Nov 22, 2005 at 08:24:18PM +1100, O Plameras wrote: > > > >>Did you compile and run the program ? > >> > >>It works. [...] > > > >Your definition of "works" is short-sighted. > > So, can you show me how you would code considering the stated results ?
I'd code it without the bug that overwrites memory you didn't allocate, as explained by Benno. Preferably, I'd do this by avoiding C and using a language like Python that makes this sort of error impossible. This is exactly the sort of bug that in many pieces of software is discovered to be an exploitable security hole. Even if a bug like this isn't exploitable in its current context, as code is modified, refactored and re-used (as so often happens), it might be later. Or maybe it'll just cause a mysterious crash one day due to the heap corruption this sort of pointer arithmetic error can cause. This can manifest as a crash during some call to malloc or free well after the corruption happened, which makes debugging difficult, particularly if you don't know how to reproduce the crash. The "stated results" aren't clear to me -- I'm not sure what problem the original code was meant to solve. However, code should be robust, and because of the pointer arithmetic bug yours isn't. This makes it a poor solution to whatever the problem is, and a maintenance headache. This is what I meant by short-sighted. -Andrew. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
