Tugger the SLUGger!SLUG Mailing List Archives

Re: [SLUG] C Gurus


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.