The first thing with Fragile Code,
there are a list of problems and you can see them there.
The one that is usually overlooked is passing pointers,
and not checking that they're valid.
Also, the parameters should be easily distinguished,
so that if you get two of them
out of order and error will occur.
The third main problem is,
having callers have access to internal structures.
This is typical when you pass pointers,
because the pointers point to the internal structures.
The user may never be intended to access them.
But on the other hand they certainly can.
So to summarize non-robust programming
introduces security problems as
well as non-security problems.
The security problems are
the assumptions that makes about the user,
about the environment, about parameters,
about things that can go wrong.
Furthermore, when something does go wrong it's often
much harder to track down where
it went wrong and how to fix it.
Whereas with a non-fragile with a robust program,
you won't have that issue.
The non-security programs as I said
makes maintenance much more complicated.
But also it's easier to make an accidental error,
and you want to avoid that.
In robust programming the key ideas are to pay
attention to everything you learned in basic programming,
about writing good programs.
We didn't talk about commenting here,
but commenting is equally important,
and yes that's stuffs you learned when you were
learning to program really does matter.
Then remember the foundations.
Robust code can handle paranoia,
robust code has paranoia in that,
it assumes people will do things bad deliberately.
Stupidity in that it assumes
people will do bad things unintentionally,
and doesn't assume they know how to use
the program of the library.
Dangerous implements which is information hiding,
and again this is something you learned in
your beginning programming classes.
Then can't happen.
Well, yes it can.
Here's a fun little puzzle for you.
About detecting overflow.
Some languages have special traps
that will be triggered on overflow or underflow.
But alas the C programming language does not.
So the usual way people detected
assuming your numbers are non-zero,
is you multiply a and b and see if
the result is less than either a or less than b,
and we're working with absolute values
here in case one of the numbers is negative.
The assumption is, if this occurred overflow occurred,
because why would multiplying two numbers,
gets you something less than that other number.
If they were floats yes but these are integers.
This doesn't always work.
Can you find a case where it doesn't,
and how would you do it right,
and I'll give you a minute to solve for that.
You can actually pause the video here,
and take a little bit longer
than that minute if you like.
Here's an example where it doesn't work.
Let's say we're dealing with decimal digits
just for ease,
and the word size is three decimal digits,
so it can store up to 999.
Let's take a and b to be 70 each.
So when we multiply a times b we get 4,900.
But the word size is three decimal digits.
So we dropped the four, overflow has occurred.
The result is 900.
But now a is 70 b is 70 and the product is 900.
So the product is greater than both a and b.
By the test we just showed,
overflow did not occur yet it obviously
did. How did you do it so?
Well the right way to do it is
this, our programming languages,
have something called maxint,
or some variable, or constant or macro or what have you.
That has the maximum integer that can be represented.
Take that and divide it by one of the numbers,
one of your multipliers.
Then see if that's less than or equal to the other one.
So in this example, maxint is 999.
So we divide it by 70, that equals 14.
Well, now we know that 14 times 70 is less than 999,
but 15 times 70 is greater.
If 15 times 70 is greater than the maximum integer,
70 times 70 is certainly going to be greater.
So the right test is what's on the slide,
divide maxint by one of them numbers,
and see whether or not it's less than or equal
to the other of the numbers,
dealing in magnitudes of course and ignoring sign.