CS 2130

1
CS 2130

• Presentation 14
• C Problems

2
Non-terminated comment

• "Accidentally" terminated by some subsequent
  comment, with the code in between swallowed.
• ab / this is a bug
• cd / cd will never happen /

3
Accidental assignment/Accidental Booleans

• if(ab) c / a always equals b, but c
• will be executed if b!0
• /
• Depending on your viewpoint, the bug in the
  language is that the assignment operator is too
  easy to confuse with the equality operator or
  maybe the bug is that C doesn't much care what
  constitutes a boolean expression (ab) is not a
  boolean expression! (but C doesn't care).

4
Accidental assignment/Accidental Booleans

• Closely related to this lack of rigor in
  booleans, consider this construction
• if( 0
• always true!
• /
• Always true because (0depending on if (0to 5, which is always true, of course. C doesn't
  really have boolean expressions, it only pretends
  to.

5
Unhygienic macros

• define assign(a,b) a(char)b
• assign(x,y8)
• becomes
• x(char)y8 / probably not what
• you wanted
• /

6
Mismatched header files

• Suppose foo.h contains
• struct foo BOOL a
• file F1.c contains
• define BOOL char
• include "foo.h"
• file F2.c contains
• define BOOL int
• include "foo.h"
• now, F1. and F2 disagree about the fundamental
  attributes of structure "foo". If they talk to
  each other, You Lose!

7
Phantom returned values

• Suppose you write this
• int foo (a)
• / buggy, because /
• if (a) return(1) / sometimes no /
• / value is returned /
• Generally speaking, C compilers, and C runtimes
  either can't or don't tell you there is anything
  wrong. What actually happens depends on the
  particular C compiler and what trash happened to
  be left lying around wherever the caller is going
  to look for the returned value. Depending on
  how unlucky you are, the program may even appear
  to work for a while. Now, imagine the havoc
  that can ensue if "foo" was thought to return a
  pointer!

8
Unpredictable struct construction

• Consider this bit packing struct
• struct eeh_type
• uint16 size 10 / 10 bits /
• uint16 code 6 / 6 bits /
• Depending on which C compiler, and which "endian"
  flavor of machine you are on, this might actually
  be implemented as
• or as
• So what matters? If you are trying to match bits
  in a real world file, everything!

9
Indefinite order of evaluation

• foo(pointer-member, pointer buffer0)
• Doesn't always work!!!
• KR and ANSI/ISO C specifications do not define
  the order of evaluation for function arguments.
  It can be left-to-right, right-to-left or
  anything else and is "unspecified". Thus any code
  which relies on this order of evaluation is
  doomed to be non portable, even across compilers
  on the same platform. This isn't an entirely non
  controversial point of view.

10
Easily changed block scope

• if( ... )
• foo()
• else
• bar()
• which, when adding debugging statements, becomes
• if( ... )
• foo() / the importance of this semicolon
  can't
• be overstated /
• else
• printf( "Calling bar()" ) / oops! the else /
• bar() / stops here /
• / oops! bar is always executed /
• There is a large class of similar errors,
  involving misplaced semicolons and brackets.

11
Permissive compilation

• CALLIT(functionName,(arg1,arg2,arg3))
• CALLIT did more than just call the function. I
  didn't want to do the extra stuff so I removed
  the macro invocation, yielding
• functionName,(arg1,arg2,arg3)
• Oops. This does not call the function. It's a
  comma expression that
• Evaluates and then discards the address of
  functionName
• Evaluates the parenthesized comma expression
  (arg1,arg2,arg3)
• C's motto who cares what it means? I just
  compile it!

12
Permissive compilation

• switch (a)
• / This initialization typically does not
• happen. The compiler doesn't complain,
• but it sure screws things up! /
• int var 1
• case A ...
• case B ...

13
Permissive compilation

• define DEVICE_COUNT 4
• char szDevNamesDEVICE_COUNT
• "SelectSet 5000",
• "SelectSet 7000"
• / table has two entries of junk /

14
Unsafe returned values

• char f()
• char result80
• sprintf(result,"anything will do")
• return(result) / Oops! result is allocated
• on the stack. /
• int g()
• char p
• p f()
• printf("f() returns s\n",p)
• The "wonderful" thing about this bug is that it
  sometimes seems to be a correct program As long
  as nothing has reused the particular piece of
  stack occupied by result.

15
Undefined order of side effects

• Even within a single expression, even with only
  strictly manifest side effects, C doesn't define
  the order of the side effects. Therefore,
  depending on your compiler, I/I might be either
  0 or 1. Try this

16
Undefined order of side effects

• int foo(int n)
• printf("Foo got d\n", n) return(0)
• int bar(int n)
• printf("Bar got d\n", n) return(0)
• int main(int argc, char argv)
• int m 0
• int ((fun_array3))()
• int i 1
• int ii i/i
• printf("\ni/i d, ",ii)
• fun_array1 foo fun_array2 bar
• (fun_arraym)(m)

17
Undefined order of side effects

• Prints either i/i 1 or i/i0
• Prints either "Foo got 2", or "Bar got 2"
• i/i 1, Foo got 2

18
Uninitialized local variables

• Actually, this bug is so well known, it didn't
  even make the list! That doesn't make it less
  deadly when it strikes. Consider the simplest
  case
• void foo(a)
• int b
• if(b) / bug! b is not initialized! /
• In truth, modern compilers will usually flag an
  error as blatant as the above. However, you just
  have to be a little more clever to outsmart the
  compiler. Consider

19
Uninitialized local variables

• void foo(int a)
• int b
• if(a)
• bmalloc(a)
• if(b)
• / BUG! b may or may not be initialized /
• ba

20
Cluttered compile time environment

• The compile-time environment of a typical
  compilation is cluttered with hundreds (or
  thousands!) of things that you typically have
  little or no awareness of. These things
  sometimes have dangerously common names, leading
  to accidents that can be virtually impossible to
  spot.
• include
• define BUFFSIZE 2048
• long fooBUFSIZ / Note Spelling of
• BUFSIZ ! BUFFSIZE /
• This compiles without error, but will fail in
  predictably awful and mysterious ways, because
  BUFSIZ is a symbol defined by stdio.h. A
  typo/braino like this can be virtually impossible
  to find if the distance between the the define
  and the error is greater than in this trivial
  example.

21
Underconstrained fundamental types

• Different compilers, or even different options of
  the same compiler, define the fundamental type
  int as either 16 or 32 bits. "Sizeof" is your
  friend!!!
• In the same vein, name any other language in
  which boolean might be defined or undefined, or
  might be defined by a compiler option, a runtime
  pragma (yes! we have booleans!), or just about
  any way the user decided would work ok.

22
Utterly unsafe arrays

• C's arrays and associated memory management are
  completely, utterly unsafe, and even obvious
  cases of error are not detected.
• int thisIsNuts4
• int i
• for (i 0 i
• thisIsNuts i 0
• / Isn't it great ? I can use elements
• 1-10 of a 4 element array, and no one
• cares /
• Of course, there are infinitely many ways to do
  things like this in C.

23
Octal numbers

• In C, numbers beginning with a zero are evaluated
  in base 8. If there are no 8's or 9's in the
  numbers, then there will be no complaints from
  the compiler, only screams from the programmer
  when he finally discovers the nature of the
  problem.
• / Line up numbersfor typographical clarity lose
• big time
• /
• int numbers 001,
• 010, / 8 not 10 /
• 014 / 12, not 14 /

24
Questions?
25
(No Transcript)