General Development Archive

Improvements to static analysis in the GCC 14 compiler

I work at Red Hat on GCC, the GNU Compiler Collection. For the last five releases of GCC, I’ve been working on -fanalyzer, a static analysis pass that tries to identify various problems at compile-time, rather than at runtime. It performs “symbolic execution” of C source code—effectively simulating the behavior of the code along the various possible paths of execution through it. This article summarizes what’s new with -fanalyzer in GCC 14, which I hope will be officially released sometime in April 2024. ↫ David Malcolm No matter how many more of you become a Patreon to keep OSNews alive, I’ll never be able to really add anything meaningful to articles like these.

Picotron: a fantasy workstation for making pixelart games, animations, music, demos and other curiosities

Picotron is a Fantasy Workstation for making pixelart games, animations, music, demos and other curiosities. It has a toy operating system designed to be a cosy creative space, but runs on top of Windows, MacOS or Linux. Picotron apps can be made with built-in tools, and shared with other users in a special 256k png cartridge format. ↫ Picotron website Picotron is very similar to PICO-8, but more powerful and with a few additional features – it’s actually made by the same people as PICO-8. It also contains a small, ‘toy’ operating system to serve as a workspace, everything makes use of Lua, and any applications made with it can be shared using a special 256k PNG cartridge format. It’s currently in alpha, and cost $11.99, and uses the early Minecraft model of a one-time purchase for access to all future updates. The FAQ has tons more information. It looks incredibly neat. I don’t have much use for it, but I’m interested to see what people with actual skills will make with it.

CAP-X and COMP-X: how the Tandy Pocket Computers got a sucky Japanese assembler

I grew up primarily with the Commodore 64, where if you wanted to do anything really cool and useful, you had to do it in 6502 assembly language. Today I still write 6502 assembly, plus some Power ISA and even a little TMS9900. I like assembly languages and how in control of the CPU you feel writing in one. But you know what would make me not like an assembly language? One that was contrived and not actually the CPU it was running on. And you know what would make me like it even less? If it were kneecapped, convoluted and limited without even proper I/O facilities. ↫ Old Vintage Computing Research Everything you ever wanted to know about CAP-X and COMP-X. Which turns out to be a lot.

Evaluation of RUST usage in space

The proposed activity is to evaluate the usage of Rust programming language in space applications, by prototyping an RTOS targeting ARM Cortex-M7 SAMV71 microcontroller together with the required BSP (Board Support Package) and a Demonstration Application. Rust safety features and its growing usage make this programming language a viable option in the space sector. It is proposed to first develop a lightweight real time operating system providing a minimal set of capabilities required for development of flight application software. This system will provide an executor, tasklets mechanisms and BSP for SAMV71. The design of the system will be guided to support potential future qualification activities. Although the project is a study, ECSS software development practices will be used to facilitate potential application in ESA projects. The practical feedback from ECSS application in Rust projects will be reported. In the second part of the activity, a small demonstration application software will be developed, providing a minimal feature-set representative of a CubeSat class project – UART communication, mode management and sensor handling. This application will showcase the viability of the developed RTOS and provide input to a Lessons Learned report, describing the encountered issues, potential problem and improvement areas, usage recommendations and proposed way forward. ↫ The European Space Agency Rust, but in space. The code’s on GitHub.

Do users write more insecure code with AI assistants?

AI code assistants have emerged as powerful tools that can aid in the software development life-cycle and can improve developer productivity. Unfortunately, such assistants have also been found to produce insecure code in lab environments, raising significant concerns about their usage in practice. In this paper, we conduct a user study to examine how users interact with AI code assistants to solve a variety of security related tasks. Overall, we find that participants who had access to an AI assistant wrote significantly less secure code than those without access to an assistant. Participants with access to an AI assistant were also more likely to believe they wrote secure code, suggesting that such tools may lead users to be overconfident about security flaws in their code. To better inform the design of future AI-based code assistants, we release our user-study apparatus and anonymized data to researchers seeking to build on our work at this link. ↫ Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh I’m surprised somewhat randomly copying other people’s code into your program – violating their licenses, to boot – leads to crappier code. Who knew!

Vcc: the Vulkan Clang Compiler

Vcc – the Vulkan Clang Compiler, is a proof-of-concept C and C++ compiler for Vulkan leveraging Clang as a front-end, and Shady our own research IR and compiler. Unlike other shading languages, Vcc aims to stick closely to standard C/C++ languages and merely adds a few new intrinsics to cover GPU features. Vcc is similar to CUDA or Metal in this regard, and aims to bring the advantages of standard host languages to Vulkan shaders. ↫ The Vcc website Note that this project is a work in progress, and has several limitations the project’s open about.

When “everything” becomes too much: the npm package chaos of 2024

Happy 2024, folks! Just when we thought we’d seen it all, an npm user named PatrickJS, aka gdi2290, threw us a curveball. He (along with a group of contributors) kicked off the year with a bang, launching a troll campaign that uploaded an npm package aptly named everything. This package, true to its name, depends on every other public npm package, creating millions of transitive dependencies. The everything package and its 3,000+ sub-packages have caused a Denial of Service (DOS) for anyone who installs it. We’re talking about storage space running out and system resource exhaustion. But that’s not all. The creator took their prank to the next level by setting up http://everything.npm.lol, showcasing the chaos they unleashed. They even included a meme from Skyrim, adding some humor (or mockery, depending on your perspective) to the situation. ↫ Feross Aboukhadijeh I know this is a bad thing, you shouldn’t do this, it harms a lot of people, etc., etc., but let’s be honest here – this is a hilarious prank that showcased a weakness in a rather playful way. Sure, there were real consequences, but it doesn’t seem like any of them caused any permanent damage, data loss, or compromised systems. What’s worse, it seems this isn’t even the first time stuff like this happened, so I find it baffling people can still do this. What are they doing over there?

The IDEs we had 30 years ago… And we lost

I grew up learning to program in the late 1980s / early 1990s. Back then, I did not fully comprehend what I was doing and why the tools I used were impressive given the constraints of the hardware we had. Having gained more knowledge throughout the years, it is now really fun to pick up DOSBox to re-experience those programs and compare them with our current state of affairs. This time around, I want to look at the pure text-based IDEs that we had in that era before Windows eclipsed the PC industry. I want to do this because those IDEs had little to envy from the IDEs of today—yet it feels as if we went through a dark era where we lost most of those features for years and they are only resurfacing now. If anything, stay for a nostalgic ride back in time and a little rant on “bloat”. But, more importantly, read on to gain perspective on what existed before so that you can evaluate future feature launches more critically. ↫ Julio Merino Fast forward to today, and the most popular text editor among programmers is a website running in Chrome in a window. No wonder most popular applications are Electron trashfires now. Times sure have changed.

Rust9x update: Rust 1.76.0-beta

20 months since the initial release, Rust9x is back, whether you like it or not! I’ve spent the last couple of days migrating the changes from Rust 1.61-beta to Rust 1.76-beta, and filling some of the holes in API support on the way. ↫ Dennis Duda Yes, this is Rust ported to Windows 9x, and this new releases comes with a lot of the benefits in 1.76, but also adds backtrace support, thread parking support, and initial work on adding 64bit support for 64bit Windows XP and newer.

The world depends on 60-year-old code no one knows anymore

The problem is that very few people are interested in learning COBOL these days. Coding it is cumbersome, it reads like an English lesson (too much typing), the coding format is meticulous and inflexible, and it takes far longer to compile than its competitors. And since nobody’s learning it anymore, programmers who can work with and maintain all that code are a increasingly hard to find. Many of these “COBOL cowboys” are aging out of the workforce, and replacements are in short supply. This puts us in a tricky predicament. We need to maintain and modernize the code that underpins so much of the business and finance worlds, but we don’t have enough skilled workers we need to carry out those updates. This is precisely the kind of problem that IBM thinks it can fix with AI. ↫ JD Sartain for PCMag It seems like learning and getting good at COBOL is a surefire way to ensure job security. I wonder if there’s a way to make modern applications or software in COBOL? I mean, there are COBOL compilers for modern platforms, of course, but are there any bindings (I think that’s the correct term?) for modern GUI toolkits like GTK, Qt, and so on? The headline’s probably a bit hyperbolic, but the core of the issue stands.

Accessibility training will not save you

I cannot pinpoint the source of this misconception, it could have been a vendor, or long-lost blog post, or one of the many webinars I attended in my early days as a program lead. Regardless of the source, I operated under the wild misconception that all I needed to do was train my teams to do accessibility. Developers, QAs, designers, all they needed was training! This model does not work. Especially for an organization with multiple products, multiple platforms, and multiple development teams. Accessibility is so much more complicated than can be summarised in a mere training. It requires experts, capable programmers, users who actually require said accessbility, and so much more. It’s also an ongoing process – it’s not a static “train once, use everywhere” kind of deal.

Swift, meet WinRT

The goal of this post is to share how we, at the Browser Company, have made it possible to use Swift to build a modern Windows application. There is no UI framework for Windows written in Swift, and Windows itself is written in C++ – so that may leave you wondering, “how can I build my app on Windows”?  Modern Windows applications use WinRT, a technology built on top of COM, which can interop really well with Swift, as we presented in our previous post. To be able to build idiomatic UI for Windows in Swift, we have built a language projection tool which creates idiomatic Swift language bindings for WinRT, and today we are open sourcing it at https://github.com/thebrowsercompany/swift-winrt. Swift/Winrt is based on Microsoft’s code generators for C++ (github.com/microsoft/cppwinrt) and C# (github.com/microsoft/cswinrt), and thus is written in C++. Cool stuff.

Thread-per-core

I want to address a controversy that has gripped the Rust community for the past year or so: the choice by the prominent async “runtimes” to default to multi-threaded executors that perform work-stealing to balance work dynamically among their many tasks. Some Rust users are unhappy with this decision, so unhappy that they use language I would characterize as melodramatic. What these people advocate instead is an alternative architecture that they call “thread-per-core.” They promise that this architecture will be simultaneously more performant and easier to implement. In my view, the truth is that it may be one or the other, but not both. A very academic discussion.

PicoCalc: a fully-functional clone of VisiCalc

The full-featured, high-precision spreadsheet application for the Pico-8 that nobody asked for has finally arrived! PicoCalc is a feature-complete clone of the 1979 classic VisiCalc, which introduced the world to an entirely new category of business application. Steve Jobs said of VisiCalc, it’s “what really drove — propelled — the Apple ][. This is a few years old already, but still an amazing piece of work.

The absolute minimum every software developer must know about Unicode in 2023

A lot has changed in 20 years. In 2003, the main question was: what encoding is this? In 2023, it’s no longer a question: with a 98% probability, it’s UTF-8. Finally! We can stick our heads in the sand again! The question now becomes: how do we use UTF-8 correctly? Let’s see! Everything you ever wanted to know about how Unicode works, and what UTF-8 does. Plus some annoying website design tricks, for which In apologise, even if it’s obviously not our site we’re linking to.

Playing with Caml Light on DOS

Caml Light is implemented as a bytecode compiler which made it highly portable. It is possible to create executables using the CAMLC.EXE command, but please be aware that the resulting binaries are not standalone when using the default linking mode, and the runtime system (CAMLRUN.EXE) is required to run them. The latest available release of Caml Light for DOS is version 0.7 released in 1995. Here’s a fun project for the weekend.

Dotfiles matter: please stop dumping files in users’ $HOME directories.

Dotfiles are important. We use them every day for storing configuration for all kinds of applications, knowingly or otherwise. You know the ones, hidden in your $HOME directory, ~/.ssh/ for your ssh keys, or ~/.Xauthority (whatever the heck that does). Something you may not know is these are legacy locations for configuration. Please do not copy their behaviour. Your application’s configuration may be the most important thing on a user’s machine. There are now standardised locations on major platforms for applications to store user-specific configuration. Your application should not be dumping random files into an unconfigurable location in the user’s home directory. This speaks to my soul.

No more stale bots!

On github, there has been an increasing trend of using “Staleness detector bots” that will auto-close issues that have had no activity for X amount of time. In concept, this may sound fine, but the effects this has, and how it poisons the core principles of Open Source, have been damaging and eroding projects for a long time, often unknowingly. I’m not a developer and even I can instantly see such bots would create countless problems. I had no idea such bots were being used.

Web apps are better than no apps

There’s a certain community in tech that’s very vocal about their preference toward native apps. I share that sentiment, yet sometimes people take this idea too religiously. Unfortunately, the actual choice is about having an app or not, and I’d rather take something over nothing. I mean, sure, but that doesn’t negate the fact that web applications – or, more specifically, Electron and Electron-like applications – are just bad. Any time I see an Electron application offered, I instantly know the developers behind the project do not respect me as a user. They choose their own convenience over my experience as a user, and while that’s a perfectly valid choice they can make, it does mean I’m not going to use your service.