Testing Your C Knowledge With This One Simple Quiz

January 23, 2024 by Maya Posch 53 Comments

One of the most exciting aspects of the C programming language — as effectively high-level assembly — is that although it’s a bit friendlier for the developer, it also adds a lot of required know-how on account of its portability across platforms and architectures. This know-how is what [Oleksandr Kaleniuk] manages to wonderfully illustrate with a simple 5-question, multiple-choice quiz on what the return value is of the provided function snippets of C code. How well do you know C?

For those who have had their run-ins with C directly (or indirectly via the support for it in languages like C++) the words ‘undefined behavior‘ (UB) are likely to induce a nervous twitch or two, along with a suspicious glance at whichever parts of reality are about to evaporate and destabilize the Universe this time. Although it is said that a proper C program is written with zero UB cases in it, in practice this can be rather tough, even before considering the other exciting ways in which a piece of code can fail to do the expected thing.

For languages other than C this is of course also a challenge, which is the reason why certification programs for e.g. avionics go out of their way to weed out such preventable issues, and only few programming languages like Ada (anything avionics, medical, etc.) and C++ (F-35 and other US DoD projects) make it into devices where failure is literally not an option.

How A Steam Bug Once Deleted All Of Someone’s User Data

January 20, 2024 by Maya Posch 14 Comments

In a retrospective, [Kevin Fang] takes us back to 2015, when on the Steam for Linux issue tracker [keyvin] opened an issue to report that starting the Steam client after moving the Steam folder had just wiped all of his user data, including his backup drive mounted under /media. According to [keyvin], he moved the standard ~/.local/share/steam to a drive mounted under /media and symlinked ~/.local/share/steam to this new location on the external drive. He then tried starting Steam, which failed, before Steam crashed and tried reinstalling itself. That’s when [keyvin] realized that Steam had apparently recursively deleted everything owned by his user from the root folder.

The infamous Valve code that made Linux users sad.

In the issue thread, user [doofy] got hit by the same bug when trying to directly start the ~/.local/share/steam/steam.sh script with debugging enabled. He then was the first to point out the rm -rf in that steam.sh script, but since this particular line is in a function only called when Steam tries to remove and reinstall itself to ‘fix’ a botched start, how did this happen? Ultimately it seems to be because of the STEAMROOT variable being set to an empty string, and another unset variable triggering the reset_steam() function, leading to the demise of all the user data.

Since then Valve has presumably fixed the issue, as no further users have filed tickets, but it’s concerning that a similar issue seems to still exist on Windows. Whether or not the original Linux issue has been fixed, it shows clearly how one should always check return values and perhaps, just maybe, never do an automated rm -rf or equivalent.

Continue reading “How A Steam Bug Once Deleted All Of Someone’s User Data” →

Open Source Needs A New Mission: Protecting Users

January 10, 2024 by Donald Papp 42 Comments

[Bruce Perens] isn’t very happy with the current state of Free and Open Source Software (FOSS), and an article by [Rupert Goodwins] expounds on this to explain Open Source’s need for a new mission in 2024, and beyond. He suggests a focus shift from software, to data.

The internet as we know it and all the services it runs are built on FOSS architecture and infrastructure. None of the big tech companies would be where they are without FOSS, and certainly none could do without it. But FOSS has its share of what can be thought of as loopholes, and in the years during which the internet has exploded in growth and use, large tech companies have found and exploited all of them. A product doesn’t need to disclose a single line of source code if it’s never actually distributed. And Red Hat (which [Perens] asserts is really just IBM) have simply stopped releasing public distributions of CentOS.

In addition, the inherent weak points of FOSS remain largely the same. These include funding distributions, lack of user-focused design, and the fact that users frankly don’t understand what FOSS offers them, why it’s important, or even that it exists at all.

A change is needed, and it’s suggested that the time has come to move away from a focus on software, and shift that focus instead to data. Expand the inherent transparency of FOSS to ensure that people have control and visibility of their own data.

While the ideals of FOSS remain relevant, this isn’t the first time the changing tech landscape has raised questions about how things are done, like the intersection of bug bounties and FOSS.

What do you think? Let us know in the comments.

FLOSS Weekly Episode 765: That Ship Sailed… And Sank

January 9, 2024 by Jonathan Bennett 5 Comments

This week Jonathan Bennett and Aaron Newcomb talk with Randal Schwartz, the longest running host of FLOSS Weekly, Perl’s biggest cheerleader, and now Dart and Flutter expert. What’s new with Randal since his last FLOSS Weekly episode in May 2020? Why should you look at Dart and Flutter? And how do you avoid becoming a security martyr?

Randal has been busy since handing over the reigns of FLOSS Weekly, adding to his Perl credentials a solid claim to being a Dart Flutter expert. The Dart language has some real appeal, taking the best features from JIT languages like JavaScript, and also offering binary compilation like a real systems language should. Then the Flutter framework lets you write your code once, and literally run it on any screen. Sure, there have been some growing pains along the way, and listen to the episode to hear Randal describe the “45-degree turns” the language/framework duo has taken through the years.

Then as almost a bonus at the end of the episode, Randal quickly covered his now-expunged conviction for “doing his job with too much enthusiasm”, and covered some basic pointers to keep other security researchers out of trouble. This week is a nostalgia trip for long-time listeners, as well as a real treat for everyone else.

Continue reading “FLOSS Weekly Episode 765: That Ship Sailed… And Sank” →

Putting The C In C64

January 8, 2024 by Al Williams 42 Comments

Older CPUs and some fairly modern microcontrollers are not made to readily support C compilers. Among those are the 1802, some 8-bit PICs, and the 6502 at the heart of the Commodore 64. That’s not to say you can’t make a C compiler for any of them, but the tricks required to handle the odd word sizes, lack of stack manipulation, or whatever other reason C isn’t a good fit tends to make compiled code bloated and possibly slower. [Dr. Mortal Wombat] took a different approach. The oscar64 compiler takes C source code and compiles it to a virtual machine code or native machine code for cases where performance might be important.

Turns out, the penalty for using native code isn’t as much as predicted, at least in some cases, The performance penalty for using the interpreter, however, can be significant in many common cases. The 6502 has a small stack that is hard to address, and indexing into a user-maintained stack is slow. The word size problem also produces lots of code as you have to break 16-bit operations into multiple 8-bit ones. The compiler aims to be C99-compliant, including floating point, recursion, multiple dimensions for arrays, and pointers to structures.

There are a few things left to hammer out. The linker doesn’t support external libraries, and the floating point code doesn’t understand NaN. On the other hand, many C++ features are available, like namespaces, reference types, templates, and more. The compiler can target several Commodore machines from the C128 to the PET. It also works with some Nintendo and Atari systems and can create various cartridge formats.

If you are writing code for any kind of 6502, it is probably worth checking out. Compiling C for the 6502 is no small feat, but then, so it is targeting PowerPoint. Don’t have a C64? Build one.

Image: [MOS6502], CC-BY-SA 3.0

A Journey Through Font Rendering

January 7, 2024 by Matthew Carlson 8 Comments

In the wide world of programming, there are a few dark corners that many prefer to avoid and instead leverage the well-vetted libraries that are already there. [Phillip Tennen] is not one of those people, and when the urge came to improve font rendering for his hobby OS, axle, he got to work writing a TrueType font renderer.

For almost a decade, the OS used a map table encoding all characters as 8×8 bitmaps. While scaling works fine, nonfractional scaling values are hard to read, and fractional scaling values are jagged and blocky. TrueType and font rendering, in general, are often considered dark magic. Font files (.ttf) are structured similarly to Mach-O (the binary format for macOS), with sections containing tagged tables. The font has the concept of glyphs and characters. Glyphs show up on the screen, and characters are the UTF/Unicode values that get translated into glyphs by the font. Three critical tables are glyf (the set of points forming the shape for each glyph), hmtx (how to space the characters), and cmap (how to turn Unicode code points into glyphs).

Seeing the curtain pulled back from the format itself makes it seem easy. In reality, there are all sorts of gotchas along the way. There are multiple types of glyphs, such as polygons, blanks, or compound glyphs. Sometimes, control points in the glyphs need to be inferred. Curves need to be interpolated. Enclosed parts of the polygon need to be filled in. And this doesn’t even get to the hinting system.

Inside many fonts are tiny programs that run on the TrueType VM. When a font is rendered at low enough resolutions, the default control points will lose their curves and become blobs. E’s become C, and D’s become O’s. So, the hinting system allows the font to nudge the control points to better fit on the grid. Of course, [Phillip] goes into even more quirks and details in a wonderful write-up about his learnings. Ultimately, axle has a much better-looking renderer, we get a great afternoon read, and fonts seem a little less like forbidden magic.

Maybe someday [Phillip] will implement other font rendering techniques, such as SDF-based text renderers. But for now, it’s quite the upgrade. The source code is available on GitHub.

A Look Inside The Smallest Possible PNG File

January 6, 2024 by Al Williams 19 Comments

What’s inside a PNG file? Graphics, sure. But how is that graphic encoded? [Evan Hahn] shows you what goes into a single black pixel inside a 67-byte file. Why so many bytes? Well, that is exactly what the post is about.

You had to guess there is some overhead, right? There is an 8-byte header. Next up is a 25-byte metadata block. That single pixel takes 22 bytes, and then there is a 12-byte marker for the end of file. Turns out, you could put a bit more in the file, and would still take 67 bytes. The metadata is in a chunk — a block of data with a type, length, and CRC. That’s why it takes 25 bytes to store the dimensions of the image. A chunk has to be at least 12 bytes long. The metadata includes the image dimensions, the bit depth, and so on.

The next chunk, of course, is the data. The data is compressed, but in the case of one pixel, compression is a misnomer. There will be ten data bytes in the data chunk. That doesn’t include the 12 bytes of the chunk overhead so that one pixel takes a whopping 22 bytes.

The end of file marker is another chunk with no data. The total? 67 bytes. However, you can add more than one bit and still wind up with 67 bytes. For all the details, check out the post.

Luckily, it is easy to pronounce PNG. You can even use the format for circuit simulation.