CS 2130

1
CS 2130

• Presentation 04
• The C Programming Language

2
Oh, Say Can You C?
3
Oh, Say Can You C?

• The C Programming Language is
• Simple
• Not too many keywords

auto break case char const
continue default do double else enum
extern float for goto if int
long register return short signed
sizeof static struct switch typedef
union unsigned void volatile while
4
Oh, Say Can You C?

• The C Programming Language is
• Simple
• Not too many keywords
• Fairly simple syntax
• Concise Doesn't require much typing

5
Oh, Say Can You C?

• The C Programming Language is
• Simple
• Useless
• Doesn't have any I/O commands
• Doesn't have strings
• Doesn't have useful math functions (use Fortran!)
• Resembles line noise
• Hard to use

6
Oh, Say Can You C?

• The C Programming Language is
• Simple
• Useless
• Complex/Complicated
• Requires libraries
• Libraries can grow in size/complexity
• Search Google for "C Libraries"
• Libraries are available by platform
• Non-standardization...always a problem
• There is an ANSI C Library

7
But how hard can it be?
8
A First Try C Program

• include ltstdio.hgt
• main()
• printf(Hello, world!\n)
• return 0

9
A First Try C Program

• include ltstdio.hgt
• main()
• printf(Hello, world!\n)
• return 0

10
Recall

• Modules can (and often should be) compiled at
  different times.
• Suppose we are compiling module A
• int x 7
• int y 42
• float z
• ...
• z someFunction(x, y)
• Is the function call okay?

11
Originally...

• C just hoped for the best
• With ANSI C things improved
• We can write
• float someFunction(int a, int b)
• / What it does /
• and we can write a prototype
• float someFunction(int a, int b)

12
The Compiler Uses the Prototype...

• ...to error check the function calls for
  parameter type and number as well as return
  value.
• The prototypes can be
• Just placed at the beginning of the file
• OR
• Placed in special files called header files (.h)
• The include statement is "including" one in our
  example (more later)

13
Header Files

• Contain prototypes
• Not libraries
• Some common header files
• stdio.h
• stdlib.h
• unistd.h
• http//www.gnu.org/manual/glibc-2.0.6/html_chapter
  /libc_toc.html

http//linux.ctyme.com/
14
Header Files

• WARNING Header files (.h) are for function
  prototypes as well as for certain items such as
  definitions of new types
• EXECUTABLE CODE SHOULD NEVER GO INTO A HEADER
  FILE!!!

15
Side Note

• While we are mentioning functions...
• Unlike Java, C does not allow function
  overloading
• Java
• public void someFunction(int i)
• public void someFunction(float x)
• C
• void someFunction(int i)
• void someFunction(float x)

16
Back to live action!

• include ltstdio.hgt
• main()
• printf(Hello, world!\n)
• return 0

OK?
17
main returns a value

• include ltstdio.hgt
• int main()
• printf(Hello, world!\n)
• return 0

To where and why?
18
main returns a value

• include ltstdio.hgt
• int main()
• printf(Hello, world!\n)
• return 0

0 means okay, right? But wait, 0 is false so
maybe it's a bad result?
19
A First Try C Program

• include ltstdio.hgt
• include ltstdlib.hgt
• int main()
• printf(Hello, world!\n)
• return EXIT_SUCCESS

OK?
20
printf prototype

• int printf( const char Format, ... )

What's this?
21
A First Try C Program

• include ltstdio.hgt
• include ltstdlib.hgt
• int main()
• (void) printf(Hello, world!\n)
• return EXIT_SUCCESS

Is this a good idea?
22
Why the (void)?

• printf(3) wants to return something
• printf(3) is a library call
• The C compiler will assume that you are just
  throwing the return value away
• You will get into the habit of ignoring return
  values of library calls
• Next thing you know...you're serving fries at
  McDonalds
• Note This is not to say that there is anything
  wrong with people who serve fries at McDonalds

The McDonalds Corporation in no way endorses
anything on this slide.
23
Truth in CS

• This is the new CS2130
• We are now using splint configured to allow you
  to ignore the return value from printf and
  fprintf
• There are times when the return value from printf
  is useful
• All other function return values must be checked!

24
But seriously...

• What are we doing here?
• Teach you how to write small test programs that
  will be graded and discarded?
• Teach you how to write programs that are part of
  large systems that control machines or devices
  that may affect human life, large amounts of
  capital, the well being of thousands of employees
  and/or stockholders?

25
Easier

• To learn how to do it the right way right from
  the start!
• Law of Primacy "That which is learned first is
  learned best"

26
But what can go wrong?
27

• June 28, 2002 NEW YORK (Reuters) - Software bugs
  are not just annoying or inconvenient. They are
  expensive. According to a study by the U.S.
  Department of Commerce's National Institute of
  Standards and Technology (NIST), the bugs and
  glitches cost the U.S. economy about
  59,500,000,000 (59.5 billion) a year.
• The impact of software errors is enormous because
  virtually every business in the United States now
  depends on software for the development,
  production, distribution, and after-sales support
  of products and services," NIST Director Arden
  Bement said in a statement on Friday.
• Software users contribute about half the problem,
  while developers and vendors are to blame for the
  rest, the study said. The study also found that
  better testing could expose the bugs and remove
  bugs at the early development stage could reduce
  about 22.2 billion of the cost.
• "Currently, over half of all errors are not found
  until 'downstream' in the development process or
  during post-sale software use," the study said.

28
Mariner I, Atlas-Agena rocket.
29
What can go wrong?

• Date July 22, 1962
• Program Mariner I, Atlas-Agena rocket.
• Cost 18.5 million
• Error Used raw value instead of average
• Result Rocket blown up by range safety officer

30
Ozone Satellites
31
What can go wrong?

• Date Mid 70's
• Program NASA satellites
• Cost 10 year delay in knowing of problem
• Error Data processing program ignored values
  that were very low.
• Result Holes in Ozone layers were not discovered
  until 1986.

32
Mars Polar Lander
33
What can go wrong?

• Date December, 1999
• Program Mars Polar Lander
• Cost 185 million
• Error Signaling problem in the landing legs
  caused by one line of missing computer code
• Result Lander lost, presumed crash-landed

34
Mars Pathfinder
35
And now a "positive" outcome

• Date July, 1997
• Program Mars Pathfinder mission
• Error System periodically reset itself, cause
  unknown
• Solution JPL engineers had fortuitously left the
  RTOS debugger/interpreter enabled in the software
  when it was installed. This allowed them to test
  and debug the mission software in situ. The fault
  was isolated, and a short C program was written
  and uploaded to the spacecraft. This program,
  when interpreted, fixed the problem
• Result No more resets occurred

36
And now a "positive" outcome

• Software designers had sacrificed "correct"
  software behavior for the sake of expediency and
  to meet mission deadlines (sound familiar?)
• Diagnosing the problem without direct access to
  the running system would have proved impossible
• Leaving the debugger installed and enabled saved
  the project
• Note JPL engineers later confessed that a few
  unexplained resets had occurred during initial
  testing. The resets were not reproducible or
  explainable, and did not occur in what were
  considered to be "mission critical" parts of the
  software. They were eventually dismissed as the
  result of "hardware glitches".

37
Bank of New York
38
What can go wrong?

• Date November 20, 1985
• Program Bank of New York Program to track
  government securities transactions.
• Cost 5 million
• Error Latest transaction continuously
  overwriting last transaction Lost 32 BILLION.
  With effort had that down to only 23.6 BILLION
  by end of the day. 5 million was interest to
  cover missing funds for 2 days!!!
• Result Bank lost confidence of investors.
• Comment Disruption of econometric models.

39
ATT Switching
40
What can go wrong?

• Date June and early July of 1991
• Program Telephone switching software DSC
  Communication
• Cost Unknown (but a bunch)
• Error After 13 weeks of successful testing
  changed 3 lines out of several million.
• Result A series of outages affected telephone
  users in Los Angeles, San Francisco, Washington,
  D.C., Virginia, W. Virginia, Baltimore, and
  Greensboro, N.C.
• Comment They knew what that change did, and they
  were confident that it did nothing else.(2) And
  presumably, the customer wanted it now.

41
Therac
42
What can go wrong?

• Date June 1985 - January 1987
• Program Therac 25. Computer controlled radiation
  therapy machine.
• Cost 6 patients died horribly painful deaths
• Error Machine had two modes Electrons, X-rays.
  Software bug caused machine to run at power
  setting 100 times too high.
• Result Patients physically felt pain from beam.
  Rapidly developed radiation sickness and died
  agonizing deaths over the course of several
  months.
• Comment First model to rely strictly on computer
  control instead of mechanical interlocks.

43
Bug Free Software

• We want bug free software
• Is it possible?
• Two strategies

44
Bug Free Software
Error

• We want bug free software
• Is it possible?
• Two strategies

Error
45
Strategy One

• You write software
• Testing department rigorously tests software
  applying specifications

46
Strategy 2

• You write software
• You build in code to handle every possible thing
  that might go wrong
• You test code knowing how code works. This
  includes testing for special cases, etc.
• You request the compiler warn you of every
  possible problem (plus you use lint)
• Testing department rigorously tests software
  applying specifications

47
Bottom Line

• We want you to program like you're an anal
  retentive paranoid delusional programmer.
• Not just for this course!

48
Fix Bugs Immediately

• Don't adopt a "bug list policy"
• Projects can and will get out of control!

49
Always Test!!!!

• But I just cleaned up a few comments!
• But I just changed a few variable names!
• But I just erased one little teeny tiny curly
  brace!

50
Reminder

• Don't be in other CS2130 lab sections.

51
Style

• Everything Returns Something
• a b c 0
• So which is better?
• a b c 0
• OR
• a 0
• b 0
• c 0

52
No such thing...

• ...as a program that is 100 correct.

53
Eiselts Lemma

• More important for a program to be understandable
  than correct

Understandability

-
Lose Lose!
Can be fixed
-
Correctness
Potential disaster
Win Win!

54
Style

• Pick a style
• Use it consistently
• Program appearance should reflect clarity of
  thought
• Precedence
• Need to look it up
• Use parentheses

55
Capital Crimes

• Doesnt compile
• Dumps core
• Spurious output
• No mercy rule
• Remember
• gcc -Wall -O2 -ansi -pedantic

56
Things to Know

• Short circuit evaluation
• break and continue statements
• ? (for optimum performance, but use sparingly)
• goto statement
• Call by Value (Pass by Value)

57
Fortran

• SUBROUTINE SWAP(I,J)
• INT T
• T I
• I J
• J T
• RETURN
• END
• IA 7
• IB 42
• SWAP(IA, IB)
• WRITE(7,1) IA, IB
• 1 FORMAT(2I10)

pass by reference
42 7
58
c

• Void swap(int i, int j)
• int t
• t i
• i j
• j t
• printf("d d\n", i, j)
• int ia 7
• int ib 42
• swap(ia, ib)
• printf("d d", ia, ib)

pass by value
42 7 7 42
59
Sneak Preview of c

• Void swap(int i, int j)
• int t
• t i
• i j
• j t
• int ia 7
• int ib 42
• swap(ia, ib)
• printf("d d", ia, ib)

Emulating pass by reference
42 7
60
Questions?
61
(No Transcript)