0.1 Pointers, memory, and structs

CSCI2520 does not require you to love C as a language, but it does require you to read C examples accurately. The course uses C because pointers, heap allocation, and low-level data layout make data-structure behavior visible in a way that high-level languages often hide.

This note therefore has one narrow purpose: make the core C toolkit readable enough that later stack, queue, and hash-table code does not feel like magic.

Why this review matters in a data-structure course

The local tutorial material says the course does not emphasize any one programming language. That is true at the assessment level. But the lecture and tutorial slides still rely on C examples to explain:

• what a pointer stores,
• how a node is allocated,
• how a structure groups fields,
• why ADT implementations hide representation details.

If you misread any of those, you do not merely get a syntax error. You lose the ability to see what the data structure is doing in memory.

Pointers store addresses, not values

The tutorial review distinguishes two operators:

• &x means “the address of x”;
• $*p$ means “the value stored at the address inside p”.

Those two ideas must not be blurred together. A pointer is not the same thing as the object it points to.

int firstvalue = 5, secondvalue = 15;
int *p1, *p2;

p1 = &firstvalue;
p2 = &secondvalue;
*p1 = 10;
*p2 = *p1;
p1 = p2;
*p1 = 20;

int firstvalue = ...; int secondvalue = ...; int *p1, *p2;

The key discipline is to separate two questions:

• what address is each pointer holding?
• what value lives at that address right now?

Dereferencing changes the pointed-to object

Once a pointer has been assigned a valid address, dereferencing it lets you read or modify the object stored there.

int x = 7;
int *p = &x;
*p = 12;

After the final line, x is 12. The statement $*p = 12$ does not create a new integer. It writes through the pointer into the existing object.

malloc allocates storage on the heap

The tutorial review also emphasizes malloc, because many data structures create nodes dynamically rather than in fixed-size arrays.

In C, the usual pattern is:

struct node *x;
x = malloc(sizeof(struct node));

Now x points to newly allocated memory large enough to store one struct node.

Two follow-up rules matter immediately:

• always check that the returned pointer is used consistently with its type;
• always know which part of the program is responsible for eventually freeing that memory.

Even when a short classroom example omits free, a real implementation cannot ignore ownership forever.

typedef shortens repeated types

The tutorial review also includes typedef, because data-structure interfaces often hide long pointer types behind short aliases.

typedef struct node *nodePtr;
typedef int stackElementT;

This does not create a new runtime object. It creates a new type name for the compiler and for human readers.

The gain is clarity:

• function prototypes become shorter,
• interface files become easier to scan,
• the ADT boundary becomes more readable.

When the course writes stackADT, the name itself is part of the abstraction. It tells you that the client should think in terms of “a stack object,” not “a pointer to some particular structure layout.”

struct groups related fields into one record

For example:

struct node {
   int data;
   struct node *next;
};

This is the standard shape for a linked-list node. One field stores the current payload, and one field stores the address of the next node.

The point is not only syntactic grouping. A struct lets you model the exact pieces of state that an ADT implementation must preserve.

struct cellT {
   queueElementT element;
   struct cellT *next;
};

How this feeds directly into ADT design

The earlier C lecture and the ADT lecture fit together tightly.

• Pointers let one object refer to another.
• malloc lets nodes be created when the operation needs them.
• struct lets the implementation store several related fields together.
• typedef helps the interface hide representation details.

So when the course says an ADT should expose the “what” and hide the “how,” the language tools above are exactly what make that separation possible in C.

Common mistakes

Quick checks

A fuller struct trace

The student example is worth reading one level more slowly, because it combines pointer setup, struct field access, file input, and ownership in one short trace.

Sdata *p;
p = (Sdata *)malloc(sizeof(Sdata));
FILE *fp = fopen("example.txt", "r");
fscanf(fp, "%s %d %s", p->name, &p->age, p->address);

There are four separate questions hidden in those lines:

1. what object does p point to after malloc?
2. which buffers receive the strings read into $p->name$ and $p->address$?
3. why does $p->age$ need an address operator while the array fields do not?
4. after the input is done, which resources must still be released?

If you can answer those four questions cleanly, you are no longer reading the code as isolated syntax. You are reading it as one ownership-and-state trace.

Exercises