Lecture 2026-2-24

Null pointers, undefined behaviour, dynamic arrays, linked-lists (in C, akin to Racket Lists), List Proccess

You will fail test-cases if you have memory-leaks.

Recall:

int *p = malloc(...);
free(p);
failing to free all allocated memory - called a memory leak.

int *p = malloc (....);
free (p);
*p = 7;//will this crash? code

• probably not since free(p) doesn't change p

  • p still points to that memory, so storing there unlikely to crash - but the location can be given out to another malloc call -> data corruption

• called a dangling pointer. BAD

Better: after free(p), assigns p to a guaranteed-invalid location

int *p = malloc(____);
free(p);
p = NULL; // null pointer - points to nothing

NULL is NOT part of the C language.

• it is defined as a constant ( in the library )equal to 0.

• Could equally well say p = 0;

Thus now, p does NOT point to anything.

Deferencing NULL

• Undefined behaviour ( UB )

• program may crash ( when will it NOT crash )

If malloc fails to allocate memory- returns NULL.

e.g.

Works, because the function does not actually use the NULL pointer, and thus doesn't actually go into the memory.

#include <stdlib.h>
int main(){
*NULL;
}

Consider again:

What does this output?

//returns the address of locally defined variable x?
int *f(){
int x = 4;
return &x;
}
int g(){
int y = 5;
return y;
}
int main(){

int *p = f();
//recall only return address of locally defined va
g();
printf("%d\n", *p);
}

• Think of the stackframe.

Thus, programs might not crash- but will behave badly.

e.g.

• 5 replaces 4

• data corruption

Never return a pointer to a local variable.

If you want to return a pointer, it should point to static, heap, or non-local stack data.

because THEY DON'T go away !

We can return pointers that were used as parameters from the caller, as we assume these pointers are working, valid, and are persisting !

int *pickOne(int * x, int *y ){
return (____)? x: y;
}

the entire point of heap is to do things like these, so we can implement getMeaPtr() like so:

struct Posn *getMeAPtr(){
struct Posn *p = malloc(sizeof(struct Posn));
return p;
}

Use the heap:

1. For data that should outlive the function that creates it ( when to use static, when to use malloc)

2. For data whose size is not known at compile-time

3. For large local arrays.

1) as above ( getMeaPtr)

2)

observe a common example of malloc

int *p = malloc(sizeof(int)) //not that useful, why not just int n?

• What if we ask for more memory (arg does NOT have to be constant)?

int numSlotsNeeded;
scanf("%d", &numSlotsNeeded);
int *p = malloc(numSlotsNeeded *sizeof(int));
//malloc sets the address of this pointer, assigning the amount of memory needed

This leads to dynamic arrays ( why? )

• can acess `p[0],...,p[numSlotsNeeded -1]

  • dynamic array ( heap-allocated)

.....free(p)

1. Programs typically have more heap memory than stack memory.

Consider example:

void recursiveFunction(int n ){
int tempArray[10008];
//eats up stack space
// for each recursive call!
...
recursiveFunction(n-1); 
}

This was akin to replicating Racket-like Structs in C ( How?)

Can we get the behaviour of a Racket list in C?

(cons x y) produces a pair x[<- ][->]y ( pointers )

Recall: Racket is dynamically typed.

C is statically typed ⇒ list items would need to have the same type.

(if not ⇒ headache)

• So no actual need for ptrs to datafields ( as they were there bc of different types )

struct Node{
int data;
struct Node *next;
//pointer to a struct Node
};

struct Node *cons (int data, struct Node *next){
struct Node *result = malloc (sizeof (struct Node));
result->data = data;
result->next = next;
return result;
}
int main(){
struct Node *lst = cons(1, cons (2, cons (3, NULL)));
// called a linked list.
}

Thus how does one "process" a linked list?

Non-tail-recursive way.

int length (struct Node * lst){
if (!lst)return 0;
//note if lst is EMPTY or is JUST the Null-Pointer, this would be false.
// but the NEGATION makes it true, hence it checks if the lst is empty or not! 
return 1 + length( lst->next);
}

OR

Using loops

int length ( struct Node * lst ){
int res=0;
for(int *cur = lst; !cur ; cur=(cur->next)){
++res;
}
return res;
}

Can we write map ( FAVOURITE FUNCTION )

int f (int n ){

}
int main(){
struct Node *lst1 = ......;
struct Node *lst2 = map (f,lst1); 
}

You can pass functions as arguments in functions. But what happens?

• The name of a function is a pointer to the function's code.

• But note, we have the name and name-definition, but we don't have environment

• Due to the "flat-environment" of C, we can get away, sometimes, by NOT using an environment.

  • Reveals the power of Racket and limitations of C compared to Racket.

But what does f look like?

• Since we know that the code coming in we can easily make declaration, and go from there:

  • We read C declaration from variable then goes outwards, smth smth smth.

    • Thus int * f(int) , from postfix before prefix, we have a declaration of a function that passes an int and returns a pointer to an int ( int * ).

This is wrong why?

struct Node *map(int *f(int)), struct Node *lst);

Fixed

struct Node * map (int (*f)(int), struct Node *lst){
if (!lst ) return 0;
return cons(f(lst->data), map (f , lst -> next));
}

Exercise: Do it iteratively.

Freeing Linked Lists.

This only releases the pointer that points to the NODE!

int main(){
struct Node *lst= cons(1, cons (2, cons (3,0)));
...
free(lst);
}

This also doesn't work, because ur going dumpster-diving. You free the pointer, just to

int main(){
for(struct Node *cur = lst; cur; cur = cur->next){

free (cur);    
}

• cur = cur -> next happens after free (cur)

• cur is dangling

• need to grab next pointer before you free.

  • How do you do that?

• we are def getting a problem that asks if a pointer is dangling.