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.