Shreyash Rai

size_t is unsigned, so counting down past zero wraps around

Fri, 03 Jul 2026 00:00:00 GMT

I had a loop that walked a vector backwards and it never terminated. The bug is that size_t is unsigned, so it can never be negative — subtracting past zero wraps to a huge positive number instead.

// Broken: when i == 0, --i wraps to SIZE_MAX, so i >= 0 is always true.
for (size_t i = v.size() - 1; i >= 0; --i) {
    use(v[i]);
}

The same trap hides in any v.size() - 1 when the vector is empty: 0u - 1 is SIZE_MAX, not -1, so a "last index" computed that way points way off the end.

One fix is to offset the index by one and count the other variable down, so the loop variable stays in valid unsigned territory:

// Fixed: i is the count remaining; the real index is i - 1.
for (size_t i = v.size(); i > 0; --i) {
    use(v[i - 1]);
}

The general rule: if a value can go negative, don't store it in an unsigned type. Reach for a signed index (or C++20's std::ssize) when you need to count below zero.

How this site works

Fri, 03 Jul 2026 00:00:00 GMT

This site is a running log of things I learn and the projects I build. The most important property it has is that publishing is frictionless: writing a new post is exactly as much work as creating a Markdown file and pushing to git. No CMS, no dashboard, no database.

The stack

It's built with Astro as a fully static site. Every TIL and every post is a Markdown file with a little frontmatter block at the top — a title, a date, some tags. Astro reads those files at build time, validates the frontmatter against a schema, and turns each one into a page. The output is plain HTML and CSS with essentially no client-side JavaScript, so pages load instantly and there's nothing to break.

There are two kinds of writing here:

TILs ("Today I Learned") — short, dated, tagged notes. This is the heart of the site and where most of the activity is.
Posts — longer writeups and essays, like this one.

Why no JavaScript framework

Because the content is the product. A personal site that's mostly text doesn't need a rendering framework shipped to the browser; it needs good typography, a readable column width, and fast loads. Keeping the build static means the whole site is a folder of HTML files that any host can serve, and there's no runtime to patch or attack.

Following along

Everything is available as a feed. There's a combined feed of TILs and posts, and if you only want one or the other, each has its own. Feeds carry the full text, so you can read without ever visiting the site — that's the point of them.

If you want to see how the sausage is made, the source is on GitHub.

Simon Willison's link blog — the format worth stealing

Thu, 02 Jul 2026 00:00:00 GMT

Kicking off a link blog here, the way Simon Willison does it: short posts that point at something worth your time with a line on why. Less pressure than an essay, and over a year it becomes the most useful thing on the site. This is the first one.

Link: https://simonwillison.net/

“…” — Simon Willison

Wed, 01 Jul 2026 00:00:00 GMT

You should blog about things you've learned, even if you don't think anyone will read it. The act of writing it up is what cements your own understanding.

— Simon Willison

Astro's Content Layer API

Sun, 28 Jun 2026 00:00:00 GMT

The glob() loader plus Zod schemas are what make every TIL, post, link, and quote on this site type-checked at build — a malformed frontmatter block fails astro build instead of shipping a broken page. Worth a read if you run any kind of content site.

Link: https://docs.astro.build/en/guides/content-collections/

Linked Lists

Mon, 22 Jun 2026 00:00:00 GMT

Introduction

Array stores data in continuous or contiguous memory.
All accessible in O(1) time, because it directly reaches address of elements inside by simple arithmetic, BECAUSE they are all stored together.
But, there's problems with this contiguous memory is that when there's no space for the next element you must copy the elements to a new location, wasting time.
That's why we use linked lists because it stores it's data in random places of the memory and each are connected.

Linked Lists

Stores data in Nodes that are spread out in memory but all nodes are storing address of the next node in the list.
Traversal time complexity: O(n)
Insertion time complexity: O(n)

Arrays vs linkedlists

a) Cost of Accessing an element

Array needs constant time O(1) because simple arithmetic leads to the next element.
Address of i th element = Base_address + i * Size_of_data_type
Linked List needs O(n) where is n is number of elements in the list.

B) Memory Requirement

Array has a fixed size, so partially filled array takes as much space as it was full.
So there's a lot of unused space in memory.
Sometimes, memory may not be available all the time since contiguous memory so it requires copying of data.
Linked List requires extra memory for pointer variables. They are 4 bytes each (in 32bit system). But 8 bytes in 64bit system.
But it does not leave unused memory.
It's usually better than array when the datatype being stored has higher size. But depends on the case on which performs better.
Nodes being stored at random places in memory.

C) Cost of insertion

In the beginning
- Arrays have to shift all elements by one and then insert the value at starting. So O(n)
- Linked List disconnects head node and reattaches new node in the beginning. So O(1)
In the end
- Arrays: Just insert element at the new free location, or copy into new array if it is full. So O(1) or O(n)
- Linked List needs to traverse until the end then attach new node. So O(n)
At i-th location (average case)
- Arrays: Shift some elements forward. So O(n)
- Linked list: Traverse i elements, so O(n)

Implementation in both C and C++

Making a node

typedef struct Node{
	int data;
	struct Node* next;
} Node;

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

Initializing Linked List

Node* A; //initialising empty LL
A = NULL; //Setting it as Null initially
Node* temp = (Node*) malloc(sizeof(struct Node)) //typecasting required, creating a new temporary node
(*temp).data = 2; //Filling data in node
(*temp).next = NULL; //Attaching it to null address
A = temp; //Setting A as temp node

Node* A;
A = NULL;
Node* temp = new Node();
temp->data = 2;           // -> is basically short form of the deferencing (*) and accessing structure with .
temp->next = NULL;
A = temp;

Node* temp1 = A;
while (temp->next != NULL){
	temp1 - temp1 -> next;
}

temp = new Node();
temp->data = 4;
temp->next = NULL;
temp1->next = temp;

#include <stdlib.h>
#include <stdio.h>

typedef struct Node {
	int data;
	struct Node* next;
} Node;

void Insert(Node** pointerToHead, int x);
void Print(Node* head);

int main(){
	struct Node* head = NULL;
	int n,x;
	printf("Enter number of nodes: ")
	scanf("%d", &n);
	for (int i=0; i < n; i++){
		printf("Enter a number: ");
		scanf("%d", &x);
		Insert(&head, x);
		Print(head);
	}
	printf("\n");
}

void Insert(Node** pointerToHead, int x){
	Node* temp = (Node*) malloc(sizeof(struct Node));
	temp->data = x;
	temp->next = *pointerToHead;
	*pointerToHead = temp;
}

void Print(Node* head){
	while (head != NULL){
		printf("%d ",head->data);
		head = head->next;
	}
	printf("\n");
}

Notes:

Node** is a pointer to pointer. Dereferencing it gives us the pointer to a Node. Then we can use -> to grab its data and next
We used pointer-to-pointer so that we can modify what is at the address of the memory. If we used pointer directly, that would not work because this new argument inside Insert would be a COPY of the pointer and not the one we want to modify.
Insert function handles both empty and non-empty linked list as if it is empty then head is null which the new temp node takes anyways.
For C++ we can use classes and the new function (Node* temp = new Node();) for easy.
This code still doesn't free up memory.

“…” — Donald Knuth

Sat, 20 Jun 2026 00:00:00 GMT

Premature optimization is the root of all evil.

— Donald Knuth