On Fri, 7 Mar 2008, Tamas Rudnai wrote:

> > In ASM you can have the most wonderful, clean piece of code, yet a small
> > illusive bug will bring it to it's knees. And finding that bug can be a
> > real nightmare even for the person that wrote the code. In a lot of cases
> > an experienced ASM programmer will get 99.99% of the code working properly
> > very quickly and it's the last 0.01% that causes all the problems.
> 
> Have you ever seen a C code where a using a single "=" instead of "=="
> caused a serious bug? A many sr. reviews the code but no ones spotting that?

Hi Tamas,

Yes I have - many times. I now forbid the use of assignment in C 
conditional expressions or function parameters by anyone working for or 
under me. But 2 points here: (1) "lint" would have picked this up and (2) 
I have been talking about HLL vs ASM not just C vs ASM. C does have some 
unique problems of its own. They are not there because it is a HLL but 
because its specific design. These problems can be overcome with disaplin.

> Have you ever seen a variable with a wrong size / signed-unsigned etc
> silently compiled but caused problem?

If you mean a small variable widenned to a bigger variable and causing 
problems due to sign. No, not for a very long time. All the C compilers 
I've used in the last 10 years have produced warnings or error messages. 
If you are getting a problem with this then it the specific compiler that 
is at fault not the HLL.

As a mater of interest, XCSB compares combinations of signed and unsigned 
variables as you would expect:
i.e.
	int	x
	uint	y

	if x < y then
		// always true if x < 0
		// always true if y > 0x7fff
	endif


> Hard to spot these too. Or a semicolon
> after an if or a while?

Again "lint" would pick this up and another reason why XCSB uses a 
different syntax

i.e.

	if cond then
	else
	endif

	if cond then
	else if cond then
	else
	endif

	if cond then
	endif

> A missing zero termination or an improperly used /
> calculated pointer?

This is a problem with C not all HLLs. A language that strictly enforces 
the way that references (pointers) are used (e.g. ALGOL 68) would not have 
this problem.

> These are just couple  of common mistakes popped into my
> mind, but look at the PC side or even bigger servers. Most of the problems
> including exploitable codes, buffer overflows etc are existing because of
> the C language (and because of architectural reason but that's another
> subject).

No, not because of the C language, because of the lack of programmer 
discipline. How many times have you seen a buffer allocated an arbitary 
size? The programmer does not know how big it should be so he just plucks 
a big number out of the air and says "right the data I'm goint to move 
into this buffer is never going to be more than this". To do it right, he 
should discover the size of the buffer he needs first OR have a buffer 
that can grow - but that is too much work for him.

This is one of the things I really hate about C, the fact that the 
language has remained static and compensated for by adding bucket loads of 
libraries. Extending the language by adding libraries means the compiler 
cannot check things for you the way it could if the extension were 
actually part of the language.

> 
> And again, this "statistic" with the 99.99% of the code working properly,
> that is again a non-language related issue (including asm). With ASM using
> macros you can reduce the chance of a mistake and increase the
> maintainability of the code.

I disagree.

> I do not like writing down a snipplet twice, I
> rather put it into a macro and instantiate it using parameters. When
> something turns out just have to fix it in one place. And if that macro is
> in a collection INC file then all the project automatically can be fixed at
> once.

That really depends on how complex your macros are. The more complex they 
are the more likely that you are fixing one problem for some 
instantiations of it and introducing other problems for other 
instantiations of it.

> Just like any other language you would do including C# / COM object /
> .NET or an Activex, whatever you use.

And just like these other languages: when you fix a bug in a library you 
need to re-build and retest everything to ensure it all still works. So 
now we are back to which is quickest to test and debug.

> 
> The two things are considarable for me is the existing libraries and
> downloadable examples, and the other thing is what Wouter pointed out. He
> said it is easier to write down this: z = sin( x->a[ 9 ] + y[ i ]->b ) then
> thinking in reverse polish logic and using macros/functions and low level
> instructions to pick up the data.
> 
> I do not know, for me it is no problem to pick up any languages quick, used
> C just too many years, used Pascal for quite a few years too, even SQL
> sometimes but my favourite is still Assembly no matter what platform or
> operating system (or without os) used. I can't tell you why, probably it is
> much more fun, or maybe because I could fit into a 10F202? :-)

I have also been using assembler and other HLL for many years and I do 
understand what you mean about getting immersed in a problem and feeling a 
great sense of satisfaction when you have solved the problem. Yes you feel 
fantastic when the only thing controlling a piece of hardware is the ones 
and zeros you have organised and forced into a piece of dumb silicon. The 
less help you get from someone or something else (e.g. a compiler and 
libraries) the greater the sense of accomplishment, but it's like running 
a marathon - you might be able to do it but if you use a car it gives you 
more time to accomplish other rewarding things :-)


Regards
Sergio
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist