Variables and Objects, pointers and addresses:

• variables and data objects are data containers with names

• the value of the variable is the code stored in the
container
• to evaluate a variable is to fetch the code from the
container and interpret it properly
• to store a value in a variable is to code the value and
store the code in the container
• size of a variable is the size of its container

'A' 16916
01000001 0100000101000100

Chapter 3, Slide 1
 overflow = a code longer than the size of the container is
being stored at a data container:
variable i
01001001100101100000001011010100

X
Problems with overflows in run-time:

(1) if the whole part X of the memory belongs to the running

program,
then
(a) if X does not contain any data important for the rest of the
execution of the program, then the program runs fine and there
is no apparent problem;
Chapter 3, Slide 2
 (b) if X does contain important data which get overridden by the
100101100000001011010100 tail of the binary code, but by
pure chance, it does not change anything (as the data stored
therein just happened to be the same), then the program runs
fine and there is no apparent problem;

(c) if X does contain important data which get overridden and

thus changed, then
(i) incorrect results may be produced or
(ii) the program may crash with all kinds of possible error
messages.

(2) if all or part of X belongs to some other process, then the

program is terminated by the operating system for a memory
access violation (the infamous UNIX segmentation fault error).

Chapter 3, Slide 3
 01000001010001…

C/c++ Compilers take care of “right overflow” for

variables by truncating the code (of course warnings
should be produced by the compiler!):

char i;
..
i = 123456789;
printf("%d\n",i);

displays 21 on the screen

Chapter 3, Slide 4
 …01000101000001

C/C++ compilers take care of “left overflow” for variables

by truncating the code

char i;
..
i = 255;
..
i++;
printf("%d\n",i);
displays 0 on the screen

100000000

Chapter 3, Slide 5
innate data types: char, unsigned char --- 1 byte
short, unsigned short --- 2 bytes
int, unsigned int --- 4 bytes
long, unsigned long --- 4 bytes
float --- 4 bytes
double --- 8 bytes
only char and unsigned char do not depend on the platform.
The values shown are typical for a 32-bit architecture.
The size of a variable (or value) can be calculated (in
compile-time) by the operator sizeof exp
Complex “data containers” - structures, records
struct {
char a;
int b;
} x;
Chapter 3, Slide 6
memory of a structure is contiguous! However the “placement”
may differ:

improper placement (from the access point of view):

variable x
x.a x.b
0100100110010110000000101101010001101101

a machine word a machine word

Chapter 3, Slide 7
 A proper placement (from the access point of view):

data variable x
completely
ignored, junk
padding
x.a x.b

01001001 10010110000000101101010001101101

a machine word a machine word

Chapter 3, Slide 8
Who creates the padding? The compiler!
Who knows the size of a structure? The compiler?
So, if we need to know the actual size of a structure, we use the
sizeof operator!

From data point of view, objects are like structures and classes
are like struct constructs.

Memory addressing:

byte 0 byte 1 byte 2 byte 3 byte 4 byte 5

Pointers: a pointer value is in essence an address, a pointer

variable is in essence a data container to hold an address.
Chapter 3, Slide 9
 8090346

byte with address

8090346

However, pointers know “data type” of whatever they reference,

with the exception of void* which is just a plain address.
A pointer “knows” what kind of object is at the end of the arrow!

Chapter 3, Slide 10
Nameless “data containers”:

byte with address

8090346

8090346

int* p
integer
"data container"

But how a pointer can “know” what is at a particular address?

Chapter 3, Slide 11
...0101 010000010100001001000011010001001100...

address address address address

802340 802341 802342 802343

What is stored in the four bytes at addresses 802340 .. 802343 ?

(a) four characters 'A' 'B' 'C' 'D'
(b) two shorts 16961, 17475
(c) long 1145258561
(d) float 781.035217
(e) nobody can tell

Of course, (e) is the right answer.

Chapter 3, Slide 12
 address
802340

...0101 01000001010000100100001101000100 1100...

802340 char* b ASCII code for 'A'

address
802340

...0101 01000001010000100100001101000100 1100...

binary code for short 16916

802340 short* s
(on a little endian machine)

Chapter 3, Slide 13
 address
802340

...0101 01000001010000100100001101000100 1100...

binary code for int 1145258561

802340 int* p
(on a little endian machine)

address
802340

...0101 01000001010000100100001101000100 1100...

binary code for float 781.035217

802340 float* f
(on a little endian machine)

Chapter 3, Slide 14
For the actual values of anything but char’s, the byte order is
important:
on a big endian machine a short with value 1 looks like this:
(Mac, JVM, TCP/IP NBO)

0000000000000001

while in a little endian machine a short with value 1 looks like

this: (Intel, most communication hardware)

0000000100000000

Normally (with variables), we do not have to worry about it, the

compiler knows it, and thus storing and fetching of values is done
appropriately. We need to be aware of it when “messing up” with
pointers and storing/fetching values through indirection.
Chapter 3, Slide 15
int AmBigEndian()
{
long x = 1;
return !(*((char *)(&x)));
}
on a big endian machine
00000000000000000000000000000001

{returns 1
on a little endian machine

00000001000000000000000000000000
{
returns 0

Chapter 3, Slide 16
Setting pointers:

(1) through dynamic allocation (malloc, new)

(2) through the address operator &
(3) through calculation -- e.g. traversing linked data structures
(4) through assignment with a special value -- e.g. memory
mapped I/O’s etc.

Indirection operator *

*p means “evaluate the data container p points to” or if on the

left-hand side of an assignment statement (as an l-value), it
means “store at the data container p points to”.

x = x + *p;

*p = x;
Chapter 3, Slide 17
End of slides for chapter 3

Chapter 3, Slide 18