c programming

16 Articles

Diagram of C99 designated initializers.

Tips For C Programming From Nic Barker

October 7, 2025 by 47 Comments

If you’re going to be a hacker, learning C is a rite of passage. If you don’t have much experience with C, or if your experience is out of date, you very well may benefit from hearing [Nic Barker] explain tips for C programming.

In his introduction he notes that C, invented in the 70s by Dennis Ritchie, is now more than 50 years old. This old language still appears in lists of the most popular languages, although admittedly not at the top!

He notes that the major versions of C, named for the year they were released, are: C89, C99, C11, and C23. His recommendation is C99 because it has some features he doesn’t want to live without, particularly scoped variables and initializing structs with named members using designated initializers. Also C89 is plagued with non-standard integer types, and this is fixed by stdint.h in C99. Other niceties of C99 include compound literals and // for single-line comments.

Continue reading “Tips For C Programming From Nic Barker” →

screenshot of C programming on Macintosh Plus

Programming Like It’s 1986, For Fun And Zero Profit

July 9, 2025 by 27 Comments

Some people slander retrocomputing as an old man’s game, just because most of those involved are more ancient than the hardware they’re playing with. But there are veritable children involved too — take the [ComputerSmith], who is recreating Conway’s game of life on a Macintosh Plus that could very well be as old as his parents. If there’s any nostalgia here, it’s at least a generation removed — thus proving for the haters that there’s more than a misplaced desire to relive one’s youth in exploring these ancient machines.

So what does a young person get out of programming on a 1980s Mac? Well, aside from internet clout, and possible YouTube monetization, there’s the sheer intellectual challenge of the thing. You cant go sniffing around StackExchange or LLMs for code to copy-paste when writing C for a 1986 machine, not if you’re going to be fully authentic. ANSI C only dates to 1987, after all, and figuring out the quirks and foibles of the specific C implementation is both half the fun, and not easily outsourced. Object Pascal would also have been an option (and quite likely more straightforward — at least the language was clearly-defined), but [ComputerSmith] seems to think the exercise will improve his chops with C, and he’s likely to be right. 

Apparently [ComputerSmith] brought this project to VCS Southwest, so anyone who was there doesn’t have to wait for Part 2 of the video to show up to see how this turns out, or to snag a copy of the code (which was apparently available on diskette). If you were there, let us know if you spotted the youngest Macintosh Plus programmer, and if you scored a disk from him.

If the idea of coding in this era tickles the dopamine receptors, check out this how-to for a prizewinning Amiga demo.  If you think pre-ANSI C isn’t retro enough, perhaps you’d prefer programming by card?

Continue reading “Programming Like It’s 1986, For Fun And Zero Profit” →

Excel Ray Tracing With Help From C

September 28, 2021 by 12 Comments

It isn’t news that [s0lly] likes to do ray tracing using Microsoft Excel. However, he recently updated his set up to use functions in a C XLL — a DLL, really — to accelerate the Excel rendering. Even if ray tracing isn’t your thing, the technique of creating custom high-performance Excel functions might do you some good somewhere else.

We’ve seen [s0lly’s] efforts before, and you can certainly see that the new technique speeds things up and produces a better result, which isn’t especially surprising. In addition to being faster, the new routines produce more detail.

Continue reading “Excel Ray Tracing With Help From C” →

ATtiny85 on circuit board with 2n2222, pushbutton, usb-c power connector, LED, and speaker.

Custom Compression Squeezes Classic Computer Choruses Into A Tiny Controller

August 19, 2021 by 14 Comments

Geeks of a certain vintage will have fond memories of games that were simplistic by today’s standards, but drew one in all the same. Their low fidelity graphics were often complimented by equally low fidelity music being forced through the afterthought of a speaker that inhabited most computers. Despite the technical constraints of the era, these games didn’t just offer gameplay. They told stories, and they were immersive in a way that some would think wouldn’t be relatable to a younger generation.

That didn’t stop [Thanassis Tsiodras] from sharing the classic “The Secret of Monkey Island” with his niece and nephew when they were young. Excited to see his family after a year of separation due to COVID-19, [Thanassis] wanted to give them a handmade gift: The music from “The Secret of Monkey Island” on a custom player. What an uncle!

[Thanassis] could have just recorded the music and played it back using any number of chips made for the purpose, but being a long time software engineer, he decided to take the scenic route to his destination. First, DOSBox was hacked to dump the speaker output into a file. Python, C, and 30 years of experience were leveraged to squeeze everything into the 8 KB storage of an ATtiny85. Doing so was no small feat, as it required that he create a custom implementation of Huffman compression to get the data small enough to fit on chip. And when it fit, but didn’t work, even more optimization was needed.

The end result was worth it however, with the music from “The Secret of Monkey Island” playing in its original form from a speaker driven by the ever so humble but useful 2n2222. [Thanassis]’ site is replete with details too intricate to post here, but too neat to miss. Watch the video below the break for a demonstration.

Continue reading “Custom Compression Squeezes Classic Computer Choruses Into A Tiny Controller” →

Ask Hackaday: Is There A Legit Use For Operator Precedence?

February 19, 2019 by 111 Comments

Computing is really all about order. If you can take data, apply an operation to it, and get the same result every single time, then you have a stable and reliable computing system.

So it makes total sense that there is Operator Precedence. This is also called Order of Operations, and it dictates which computations will be performed first, and which will be performed last. To get the same results every time, you must perform addition, multiplication, power functions, bitwise math, and all other calculations in a codified order.

The question I’ve had on my mind lately is, does this matter to us or just the compiler?

Continue reading “Ask Hackaday: Is There A Legit Use For Operator Precedence?” →

Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™

January 22, 2019 by 58 Comments

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™” →

Warnings On Steroids – Static Code Analysis Tools

December 12, 2018 by 11 Comments

A little while back, we were talking about utilizing compiler warnings as first step to make our C code less error-prone and increase its general stability and quality. We know now that the C compiler itself can help us here, but we also saw that there’s a limit to it. While it warns us about the most obvious mistakes and suspicious code constructs, it will leave us hanging when things get a bit more complex.

But once again, that doesn’t mean compiler warnings are useless, we simply need to see them for what they are: a first step. So today we are going to take the next step, and have a look at some other common static code analysis tools that can give us more insight about our code.

You may think that voluntarily choosing C as primary language in this day and age might seem nostalgic or anachronistic, but preach and oxidate all you want: C won’t be going anywhere. So let’s make use of the tools we have available that help us write better code, and to defy the pitfalls C is infamous for. And the general concept of static code analysis is universal. After all, many times a bug or other issue isn’t necessarily caused by the language, but rather some general flaw in the code’s logic.

Continue reading “Warnings On Steroids – Static Code Analysis Tools” →