On Tue Nov 22, 2005 at 19:39:54 +1100, O Plameras wrote: >Benno wrote: > >>On Tue Nov 22, 2005 at 18:55:24 +1100, O Plameras wrote: >> >> >>>Benno wrote: >>> > >It is a problem with not checking with the manual, not a pointer >problem. The reality is the >program works because it does what it was expected to do, i.e., print >the required string.
It isn't a problem with the manual it was a problem with the understanding of how strings are represented in the C lanague. >You cannot show a situation where that code will not print the correct >string, because the >original poster has a '\0' at the end of the You didn't allocate enough memory for the string! You strcpy()ed all over the top of some memory you didn't own! If he had already malloced some data just after that you just nuked it! I mean it is just such a classical C error from which you so often get exploits. It is this type of "oh well it works here" attitude that leads to the giant mess of software systems that exist. Because chances are that code will be reused through the joy of CAP technology and then used somewhere else, where that buffer overrun will matter. >If it crashes then a fairly knowledgeable programmer just run 'gdb' >after compiling with a >'-g'. It is not big deal. Its bad because it will crash in subtle ways. i.e: it will overwrite someone else memory. Which is subtle, and isn't easy to track. And might not cause something to crash, but cause you monthly accounts to be over by $100. It is a big deal if that code is running on a customers embedded device in the field. >But if the codes themselves are badly written, then it is a big problem. Sure, but on C the code often has to be complicated because a/ It is inherent in the problem being solved. b/ The language doesn't give you good tools. (E.g: syntax + library) to deal with complex problems. >>I don't >>have a problem with pointers. I use them every day, they aren't scary. >>Being a good programmer in any language means understanding pointers. >> >>*But* there are better ways to refer to abstract data types >>than through pointers. Really. >> >> >> >>>The reality of it all is anyone can learn C in one day and master it in >>>one week. >>> >>> >> >>That is total crap. Having gone through a C programming course, and taught >>one at university I know that to be plainly untrue. >> >> >> > >So , why you write such a complicated looking code, when it is a lot simpler It isn't really that complicated it it a couple of pointer derferences. And, as I already explained I was simply fixing the code based on the existing design, not rewriting as I would have done. I also made a generalisation about the problem and assumed that Ashley was preparing to write a function that actually returned a computed string, which as explained in depth elsewhere requires significantly more work than just returning a static string. (Because if Ahsley just wanted a static string he could have just used one, the function becomes entirely redundant). And also because I yearn to teach and impart knowledge on those trying to learn C by explaining what the pointers meant, so that in the future Ashley and others on the list would have learnt something about pointers. I don't know wether I succeeded or not, I got a thanks from Ashley and he didn't ask any follow ups, so I assumed it helped, maybe I'm misguided. I also pointed out elsewhere the simplest possible program that can achieve the same output, but I think you'd agree that that isn't very interesting, except from a mental masturbation how small can I make it point of view. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
