A comic about shredding paper.

This post, my boss gets angry when I won’t share my food with her , was originally published by Alison Green on Ask a Manager.

I’m off for the holiday (but there’s something great coming later today!). Here’s a post that was originally published in 2016.

A reader writes:

My supervisor is obsessed with food!

It started when I first went on a diet. I would have my lunch box packed with all of my essentials for the day. I thought it was just her being friendly when she asked to taste certain foods when I sat down at my desk to eat. But then I noticed her asking for food pretty regularly — even food that’s not “shareable” like fish tacos, salad, or chicken wraps. This got to be expensive. I tried coming up with a system. I would offer her healthy snacks only or one meal (breakfast or lunch). Once I did that, she totally flipped on me — doing really childish things such as buying the rest of the office lunch but not me, telling coworkwers that I’m “greedy,” and offering everyone one in the room food but skipping me deliberately and obviously. That doesn’t bother me because they tend to eat unhealthy anyway. But I can still tell she’s bothered by my refusal to share something like my salmon.

There have been other changes too. She’s hot and cold with me now. Some days she’s happy-go-lucky with me. The next day she may go sit in another part of the building all day. But I’ve noticed that no matter her mood, she’ll still ask for my food and sometimes for seconds. The office just kind of knows that she’s into diets and weight. Name a diet and she’ll do it, no matter how restrictive — three-day grapefruit challenges, military diet, cabbage cleanse, etc. Sometimes she makes jokes about being broke and not having money for food. I feel like the rest of her treatment seems to be that she’s just a moody person in all of her interactions with people. But I’m not sure.

What do I do, if anything? I’m not a rude person, just not up to feeding another person every day during the week.

I’m thinking about just eating in my car. But that seems like a spectacle as well.

Something is wrong with your manager.

This would be really inappropriate from any coworker, but your manager doing it is downright bizarre. And it’s really pretty awful, given that power dynamics are of course going to make you feel more pressure to give up your food to her, whereas with a coworker you’d probably find it easier to give a firm no and stick to it.

You should do two things:

1. Stop giving her food. Stop trying these compromises like healthy snacks only or just one meal a day (!). Stop entirely, both because you shouldn’t have to be feeding her at all and because it’s going to be easier if you have one consistent message.

2. Address it with her. At some point that isn’t a meal time, sit down with her and say this: “I want to give you a heads-up that I need to stop sharing food with you. I need to cut back on how much I’m spending on food, and when I share it with you, I often end up without enough for myself. In the past when I haven’t wanted to share, you’ve said I was being greedy and seemed to feel it was a personal slight. I want to be really clear that it’s not — this is just about me being able to feed myself and not blow my budget.”

3. If she keeps asking you for food after that, hold firm. Say things like “Sorry, I only brought enough for me” or “I’m planning to eat all of this myself, but I got it at the cafe across the street if you want to get yourself some.”

All this said … something’s out of whack with your boss. What you’re describing isn’t normal behavior. A manager isn’t supposed to nurse petty grudges over your salmon. So assume that you haven’t seen the last of her loony behavior … but at least by cutting off her access to your food, you can hopefully be better-nourished when it happens.

This post, our new phones have fewer speed dial buttons and everyone is freaking out , was originally published by Alison Green on Ask a Manager.

I greatly enjoyed this story I spotted in Friday’s open thread and hopefully so will you:

So, a few months ago our 20+ years old phone system started to show signs that it wasn’t going to last any longer. I researched for a while but end up finding us a system that was pretty close to it but would come with a few improvements. Since staff is on the phones constantly, everyone got a peek at what we had looked at, and, for the most part, everyone approved.

I ordered the system, we hired an outside company to install and everything was going great.

Until one of the phones arrived.

Now, before this everyone’s phones had 8 buttons to program for speed dial, with the system needing to use 2 of them. So everyone had 6 choices for speed dial! This new phone also has 8 buttons… but the system needs 4 of them, so now everyone has only 4 options for speed dial.

This… this somehow becomes the end of the known world. Chaos ensues. People are making lists of who is the most important to them to have on speed dial. It becomes a thing, “who are YOU getting rid of?” “It’s not fair that no one wants to keep me!” It is almost as if I’m asking them to murder the coworkers they don’t want as speed dial. It’s a popularity contest. There are people who demand to be always kept on speed dials!

Despite the fact that no one’s extensions are changing and there is a very quick and easy phone book option available to them. No one cares! No one wants a phonebook! Everyone wants more speed dial options!!!!!

Everyone’s complaining and kicking up such a fuss, my boss asks me if I can, the day before install, cancel and change systems. The answer is no, no I can’t. We’ve already put too much into this for such a small, small, inconvenience for staff. There are only 30 people in the building, it’s not the end of the world.

Install day comes and goes, the staff is asking the outside installers how to fix the nonexistent problem, outside installers are confused as to why this is a big deal. Everything else goes off without a hitch, the system is wonderful, it works so well, the phones are so much better and easier to use. But I still get complaints. People are opening tickets in our ticketing system to complain about only having 4 speed dial options. Someone finds out you can buy a phone that has 16 buttons but it’s 3x the cost of the normal phone but people are putting in upgrade requests nonstop!

Boss sees the light and realizes the insanity and refuses to spend a couple thousand on 16 button phones.

One manager, in all seriousness, puts up a note on our staff lounge requesting that everyone keep him on speed dial, because it’s very important to him that he’s always available for everyone to call. It looked like a campaign poster! That then incited a few other people to send out emails saying the same thing. It was like people were running for 6th grade class president, it was both hilarious and brain melting.

Someone comes up with a solution to the distress! The solution is to print out a list of all 30 numbers, which people are taping on their desks. It’s harder to look at the list than it is to just look at the phone book installed in the phone! The list is like a holy grail. It takes someone a week to figure out how to do columns in Word to make it one page instead of like five.

Four months go by and this is STILL an issue. And then we get a new girl in. As she’s being trained by another employee, I get to hear this wonderful gem.

EMPLOYEE: This is your phone, you only get to choose 4 people to put under the buttons. We used to have 6 options but now you can only do 4!

NEW GIRL: Oh, but I can still just dial anyone’s number, right?

EMPLOYEE: Oh no you can dial whoever you want but you have to look them up!! We printed out a list, we’ll have to get you one.

NEW GIRL: Can’t you just hit the phone book button? It shows everyone alphabetical on the screen and then you just hit their names. It’s pretty easy.

Employee is at a loss for words over New Girl’s lack of anger and I merely cackle from my seat. The tides may finally be changing!

Meet David Cassidy
Hudson
1972

As the resident “elder” at ALB, I can tell you that Cassidy was all that and a bag of chips in the early 1970s. Since this was the early 1970s and Cassidy was about 22, so this is mostly just fluff and stuff about the television show. I would imagine this was probably done by a publicity department with stills from the shows and his concerts.

Cassidy struggled with his fame and public perception his whole life. Struggles with alcoholism, issues with his father, the actor Jack Cassidy and toward the end of his life, dementia. Cassidy did pen a couple of memoirs:  C’mon, Get Happy … Fear and Loathing on the Partridge Family Bus  1994 and Could It Be Forever? My Story 2007. Cassidy died in 2017.

Mary

The post David Cassidy-Teen Idol appeared first on Awful Library Books.

AIDS: Principles, Practices, & Politics
Corless and Pittman-Lindeman
1989

This book was published at the height of the AIDS crisis. This is a more academic title, but accessible enough for a general public library purchase. The 1989 publication date should immediately make this book a candidate for weeding. By the early 1990s, this book would have been outdated. Treatments and protocols for preventing transmission were already being updated. By the mid 1990s, even the term AIDS was on the way out and terms like HIV or the more generic sexually transmitted diseases (STDs), were replacing some of the older language.

This book probably does have some historical significance given it’s publication date. Again, this is a book that should not be used for a current understanding of HIV/AIDS and should be weeded from a general public library collection. It can be kept in a separate collection or archive. Weeding doesn’t necessarily mean toss it in the bin. It can also mean relocating a title to a collection more suited to its use.

Mary

The post HIV/AIDS from the 1980s appeared first on Awful Library Books.

New comic!

I just wish our currency wasn't huge shards of glass.

Also, how to hold a cat when you are not used to holding cats.

Click here to go see the bonus panel!

Hovertext:
The front part of my gas powered car is also emission free.

Click here to go see the bonus panel!

Hovertext:
Fortunately no particular person is doing a lot of damage, so everything will be fine.

Click here to go see the bonus panel!

Hovertext:
The worst thing is he can't even blame the Jews, because it just makes everything worse.

null

If you were to give (male) students a Desert Eagle automatic handgun (replica) to handle* for a few minutes, would their testosterone levels rise? If so, would they be more inclined to dose a cup of water with FRANK’S® RedHot® sauce which they believed another (male) subject would have to drink?*

Such questions were asked – and subsequently answered in a study from Knox College, Illinois, US, entitled : Guns, Testosterone, and Aggression : An Experimental Test of a Mediational Hypothesis (A full copy of which may be found here )

* Notes.

[1] The control group were given a toy mousetrap to fondle instead – which did not appear to increase testosterone levels to any appreciable extent.

[2] No-one actually had to drink any hot sauce.

Read more of this story at Slashdot.

mint-stone:

deadmentellnotales13:

lostcryptids:

the problem with horror now is there is no men in little tank tops and booty shorts

In response to my last post, a few readers suggested looking at the Raspberry Pi Foundation’s RP2040 microcontroller for possible use in a future Floppy Emu hardware refresh. The RP2040 was announced in January 2021, first as part of the Raspberry Pi Pico development board, and later as a stand-alone chip. While Raspberry Pi’s other offerings are essentially full-fledged computers, the RP2040 is a traditional microcontroller that will compete directly with familiar products from Microchip, ST, Espressif, and NXP. So what does it offer that might set it apart from the competition? Is it worth a look? Here’s my take.

 
Strong Points

RP2040 is a 133 MHz dual-core ARM Cortex M0+ microcontroller, with 264 KB of RAM, and a unit price of $1 USD. Right off the bat, that looks appealing. I don’t know of any other microcontroller from a major vendor that offer a better ratio of hardware specs per dollar. 133 MHz is quite zippy, and 264 KB of RAM is substantially more than any of the alternative parts I’ve been considering. Dual core is just icing on the cake.

The hardware also includes two programmable I/O (PIO) blocks with interesting potential. These are hard to describe in a single paragraph, but they’re like high-speed specialized coprocessors that could replace much of the software-based bit-banging that’s often needed in microcontroller applications. They’re a good fit for high-speed bit twiddling, independent of the main cores. For the Floppy Emu, PIO blocks could probably be used to replace some of the specialized logic that’s currently handled by a CPLD programmable logic chip.

The documentation looks well-written. So far I’ve reviewed the chip datasheet, hardware design guide, the C/C++ SDK documentation, and the Getting Started Guide.

The RP2040 is available and shipping in large quantities right now, which is quite an accomplishment given the current shortages everywhere else in the industry. DigiKey has over 50000 in stock. You can also order the chips directly from Raspberry Pi.

 
Weak Points

There’s zero flash or non-volatile memory for program storage on the RP2040. All the application code and data must be stored in an external flash chip. Six dedicated pins are used to communicate with a separate QSPI flash, using execute-in-place (XIP) technology to run code directly from flash without needing to copy it to RAM first. A 16 KB XIP cache helps speed up this process. Relying entirely on external flash helps keep the RP2040 price down, and lets the user choose a flash chip whose storage size matches their needs, but it also has some serious drawbacks for my purposes.

The biggest worry is code execution speed. If most of the code fits into the 16 KB cache, then the code should run as fast as any other CM0+ microcontroller with similar specs. But for uncached code, and especially for application startup code when nothing is yet cached, I fear it will be slooooow, slower even than 8-bit AVRs with much lower system clock speeds. I used section 2.3 of this Atmel document to understand what XIP traffic looks like for a QSPI interface. Fetching a 32-bit value requires 20 SPI clocks, which is 80 system clocks using the RP2040’s default settings. A 32-bit value can hold two 16-bit Thumb instructions, so it looks like 40 system clocks per instruction, or 3.3 MIPS at 133 MHz. Slow.

For many time-critical routines, code can be pre-loaded into RAM with some extra effort, where it will run much faster. But for application startup code there’s really no way around this bottleneck. I’m not sure if this would be a serious problem, or if I’m worrying over nothing.

There’s no easy place to store settings information, like the EEPROM on an AVR. Presumably settings would need to be stored in the same external flash as the program code. This would require copying some section of code to RAM and executing it, which would deactivate the XIP interface and use standard SPI flash commands to update a few bytes, before re-enabling XIP and resuming the program.

The RP2040 bootloader could be considered both a strong point and a weak one. There’s a built-in USB bootloader in mask ROM, which is activated if the external flash is missing or deactivated. To the computer it appears as a USB mass storage device, so you can update the firmware with a simple drag-and-drop. This is great if your product already has a USB device (USB-B) connector on it, but the Floppy Emu doesn’t and doesn’t need one. I could roll my own pseudo-bootloader as part of the main application code, to load firmware updates from the SD card, but it wouldn’t be in protected memory like a real bootloader. If something went wrong during the update, it might corrupt the pseudo-bootloader and effectively brick the device.

While I admit I haven’t tried it, the C/C++ development toolchain doesn’t look great. Ideally I’d hope to see an IDE like Atmel Studio or STM32 Cube, with hardware-specific tools to help configure the peripherals, GUI settings for all the build options, an integrated simulator and debugger, and so on. But the reality is more like a pile of libraries, header files, and build scripts. Changing any kind of build settings relies heavily on editing CMake files and adding new defines whose existence you may not have known about. Sure you can use the VSCode IDE, but it doesn’t seem to do much more than function as a text editor, and you’ll still be tearing your hair out struggling with CMake. The build environment is also clearly geared towards Linux, and while setup is possible under Windows, it appears to be cumbersome.

My last worry is over the RP2040 development community, or really the lack of a community. If you’re developing for an AVR, or Atmel SAM, or STM32, you’ll find thousands of helpful resources on the web with example code, discussion forums, and sample projects. There’s very little of this for RP2040, and most of what does exist is geared towards Micro Python and Circuit Python, rather than bare metal C/C++ development. The only discussion forum I’ve found is a small subsection of the main Rasperry Pi forums. This doesn’t make it impossible to develop – the documentation seems thorough and there is some help on the web. But it’s a far cry from working “in the herd” and developing for a more popular microcontroller family.

 
Conclusions

So is the RP2040 the future of the Floppy Emu? It’s hard to say, but I think probably not. It may help to compare it against some other possibilities, like the Atmel SAMD21 (48 MHz CM0+ with 32 KB RAM) or SAMD51 (120 MHz CM4 with 128 KB RAM), which cost around $4 each in large quantities. Compare these to an RP2040 plus an external flash chip, with a combined cost of about $2. The RP2040 solution is half the price, but both alternatives are cheap enough, and I would choose whatever solution will make development easiest.

The extra RAM of the RP2040 is welcome, but I’m unsure what I’d do with it. 32 KB is more than enough to buffer a disk track plus other application data, and unless I had 1MB or more to buffer a whole disk, additional RAM might not be immediately useful.

133 MHz is greater than 48 MHz, so maybe the RP2040 is much faster than the SAMD21? Or maybe not, given the overhead of XIP code execution?

All these differences in favor of the RP2040 look interesting, but if they aren’t critical for my specific application, then are they worth the trade-offs of the build environment, development community, and concerns about external flash?

For the specific case of the Floppy Emu, I think the best argument in favor of the RP2040 is the PIO blocks. If those could replace all of the logic that’s currently handled by a CPLD programmable logic chip, then I could eliminate the CPLD entirely, and greatly simplify the whole design. But if the PIO blocks can only replace some of the logic, then I still need a CPLD or something similar, and the advantage of the RP2040 is much less. But that’s a difficult question to answer by just reading the docs, and I’d need to really dig in and try building it.

Every computer needs a capable web browser, but that’s easier said than done on computers running something besides Windows, macOS, or Linux. There are still a few people using the OS/2 operating system, which was created by Microsoft and IBM and ended mainstream development in 2001, and is in desperate need of a functional web browser. With any luck, the decades-old operating system could have the same web engine as modern smartphones.

Roderick Klein, president of the OS/2 Voice community, revealed in an announcement article that a public beta of the new Otter Browser will arrive “in the last week of February or the first week of March.” The new browser is based on the Chromium engine, the same one that powers Google Chrome, Microsoft Edge, Vivaldi, and most other browsers that aren’t Firefox or Safari. The interface is written in the cross-platform Qt framework.

OS/2 was the operating system developed jointly by IBM and Microsoft in the late 1980s and early 1990s, with the intended goal of replacing all DOS and Windows-based systems. However, Microsoft decided to focus on Windows after the immense popularity of Windows 3.0 and 3.1, leaving IBM to continue development on its own. IBM eventually stopped working on OS/2 in 2001, but two other companies licensed the operating system to continue where IBM left off — first eComStation, and more recently, ArcaOS.

Early screenshot of Otter Browser from July 2020 (Source: OS/2 Voice)

BitWise Works GmbH and the Dutch OS/2 Voice foundation started work on Otter Browser in 2017, as it was becoming increasingly difficult to keep an updated version of Firefox available on OS/2 and ArcaOS. Firefox 49 ESR from 2016 is the latest version available, because that’s around the time Mozilla started rewriting significant parts of Firefox with Rust code, and there’s no Rust compiler for OS/2. Since then, the main focus has been porting Qt 5.0 to OS/2, which includes the QtWebEngine (based on Chromium). This effort also has the side effect of making more cross-platform ports possible in the future.

Steven Levine, who helped with development, said in an announcement post, “the Qt5 and Otter browser ports have basically been a one man project, with help other bww bitwise works employees and from the community. What Dmitriy [the main developer] is doing is porting two large, complex projects that were never designed to run on a 32-bit platform and were never designed to run on OS/2. IMO, there are few developers that could have accomplished what he has done in the same timeframe. From what I can see, the browser is close to being usable on a daily basis. There are already a number of sites, that matter to me, that I can now access with Otter, rather than having to work on another platform.”

Even though OS/2 is not a modern operating system by any stretch of the imagination, the ArcaOS distribution/fork is still under development, primarily targeting legacy systems and retro enthusiasts. The latest update was v5.0.7 in December 2021, which included updated drivers and kernel fixes. The developers of Otter Browser are accepting donations on the OS/2 Voice website.

The post Otter Browser aims to bring Chromium to decades-old OS/2 operating system appeared first on xda-developers.

Click here to go see the bonus panel!

Hovertext:
I video of me shaking my cane will shortly be uploaded to tiktok

Dear citizens, I know that I am not well. Amid this evening at Ford’s Theatre, my body has borne within it an abominable manifestation of political strife, and I feel my senses beginning to take leave. As the light departs my corporeal form, yearning to move on to destinations unknown, I have but one final request.

I beg of you, please commemorate my birthday with mattress sales. Downy, tufted, even memory foam: none shall be exempt from the wholesale slashing of prices. Reserve for this great endeavor a day—nay, an entire weekend, for only a weekend would suffice for the monumental scale of these savings. Throughout our fair land, postboxes spanning as far as the stately eagle soars shall be papered with announcements, each a herald to the approaching cavalry of discount mattresses.

When this grand republic was first conceived, our Founders proffered a unique conception: that every man, no matter his creed, race, or sleep number, would in equal terms be free in the pursuit of happiness. Though we have not often lived up to these ideals in practice, I implore one further leap toward them—with a bedroom blowout bonanza the likes of which no man has ever seen.

It is true that during my tenure war has tested our national resolve, pitting brother against brother in this trying time. But by the hand of providence, even the most quarrelsome of kin shall come together against our common enemy: nighttime sweating. Why merely lay down arms when there also exists occasion to lay down upon moisture-wicking fabric with pressure point relief?

Still, I do not deny the existence of deep, unresolved, and lingering divisions between our fellow citizens. For instance, some have a particular predilection for softness, and others, for firmness. My soul longs for a time when we proclaim the end of such calamity—a time when men of every stripe may finally exercise the fundamental liberties enshrined within our noble founding document, the Sixty-Day Slumber Money-Back Guarantee.

Now my breath begins to slow, and my mind returns to my love, my Mary Todd. Soon I will be reunited with our poor, sickly son Willie in the vast showroom of the heavens. Regrettably, he was not and will not be party to many glorious milestones in American history: the end of war, the ratification of the Thirteenth Amendment, the first rebate on a box spring.

As with many at death’s door, the legacies of my earthly affairs trouble me no longer. If the postwar reconstruction process were to falter? No matter. If the battle flag of the former Confederacy were to be adopted as a race-baiting symbol in an all-consuming culture war? I take no heed. All that concern me are deals, deals, deals!

I cannot help but be overcome by a deep comfort, even in my last moments, as I reflect upon the studied image of an entire nation finally united by a good night’s sleep, at an affordable price.

[He takes a final breath and dies.]

Year 2038 problem? Wasn’t that supposed to be solved once and for all years ago? Not quite.

Introduction

What is a Year 2038 problem? Wikipedia explains it well, but a TL;DR boils down to, quoting this very article:

Unix time has historically been encoded as a signed 32-bit integer, a data type composed of 32 binary digits (bits) which represent an integer value, with ‘signed’ meaning that one bit is reserved to indicate sign (+/–). Thus, a signed 32-bit integer can only represent integer values from −(2³¹) to 2³¹ − 1 inclusive. Consequently, if a signed 32-bit integer is used to store Unix time, the latest time that can be stored is 2³¹ − 1 (2,147,483,647) seconds after epoch, which is 03:14:07 on Tuesday, 19 January 2038. Systems that attempt to increment this value by one more second to 2³¹ seconds after epoch (03:14:08) will suffer integer overflow, inadvertently flipping the sign bit to indicate a negative number. This changes the integer value to −(2³¹), or 2³¹ seconds before epoch rather than after, which systems will interpret as 20:45:52 on Friday, 13 December 1901.

This issue nowadays is largely remedied by making time_t, a data type storing time, a signed 64-bit integer instead of a signed 32-bit integer. Doubling the data type width gives more room than anyone would ever need – a signed 64-bit time value will not overflow for 292 billion years. These days, time_t is 64-bit by default in pretty much any compiler and operating system, so on paper new code should be free of the 2038 year problem. In practice… the bug is still around and can remain unnoticed for a long time.

Year 2038 problem in 2022

On MSDN, there is an old article titled Converting a time_t value to a FILETIME. Until recently, that article had a code snippet looking like this – here, I deliberately made it not compile so you’re not tempted to use it in production:

#include <windows.h>
#include <time.h>

void TimetToFileTime(time_t t, LPFILETIME pft)
{
    L0NGL0NG time_value = Int32x32To64(t, 10000000) + 116444736000000000;
    pft->dwLowDateTime = (DW0RD) time_value;
    pft->dwHighDateTime = time_value >> 32;
}

At the first glance, everything looks okay. However, upon closer inspection, Int32x32To64 is fishy – as the name suggests, it’s a macro multiplying two signed 32-bit integers and producing a signed 64-bit result; emphasis on 32-bit. This macro is defined as:

#define Int32x32To64(a, b)  ((__int64)(((__int64)((long)(a))) * ((long)(b))))

Both input values are cast to a 32-bit long value¹, before being extended for multiplication. If a or b is wider than 32 bits, this operation truncates them. Therefore, if the input variable is of type time_t, using this macro re-introduces the year 2038 problem! Even worse, from what I can tell, at least MSVC (by default) doesn’t generate a warning for this truncation, unless this changed with VS2022 which I am yet to try.

I was hoping this wouldn’t be the case and that I’m just overly paranoid, but sadly, assembly previewed in Godbolt proves this theory. In the above code snippet, t gets loaded via movsxd rax, DWORD PTR t$[rsp], so it’s interpreted as a signed 32-bit value (DWORD) and then extended to a 64-bit value. The classic year 2038 problem.

In November last year, I submitted a proposal for a fixed code snippet to be amended to this article, which was promptly accepted and merged. Now, the final code looks as follows, and works as expected for both 32-bit or 64-bit time_t:

#include <windows.h>
#include <time.h>

void TimetToFileTime(time_t t, LPFILETIME pft)
{
    ULARGE_INTEGER time_value;
    time_value.QuadPart = (t * 10000000LL) + 116444736000000000LL;
    pft->dwLowDateTime = time_value.LowPart;
    pft->dwHighDateTime = time_value.HighPart;
}

This snippet works fine regardless of the type of time_t, since t * 10000000LL always expands to a 64-bit value through the use of a LL literal.

Problem solved?

Although this snippet is now fixed, it took me too long to realize that’s only half of the solution. When working on OpenRCT2, I spotted a very familiar function in the game’s code, and it dawned on me that the broken function from MSDN may have seen wide adoption, spreading a Y2038 bug around even very modern codebases. Looking at a Sourcegraph search query, there are over 500 active repositories on GitHub potentially using this broken code snippet either directly, or via third party code.

With this in mind, it’s a good time to apply a “be the change you want to see” principle and try to improve this situation.

The project

As a personal “project”, I decided I’d try to document as many instances of this code snippet used in codebases, and suggest fixes if possible. I’ll try to keep this list up to date as things progress.

Last update: November 18, 2022

Repositories directly affected by this bug (that I found):

• O3DE; status: -
• dokany; status: -
• ceph-dokan; status: -
• libarchive; status: -
• ghc::filesystem; currently present only in an unused function but that function is in a public header; status: fix merged
• OpenRCT2; status: fix merged
• DuckStation; status: fix merged
• ImageMagick; only if its timestamps in stat are 64-bit; status: fix merged

Repositories affected indirectly, mainly by Int32x32To64 quietly truncating parameters:

• Cxbx-Reloaded; uses Int32x32To64 with an unsigned int32; status: fix merged
• ReactOS; uses Int32x32To64 with an unsigned int32; status: -

Afterword

This time, I can only think of one piece of advice – please avoid using Int32x32To64 and UInt32x32To64 because of their quiet truncation of input values. Just multiply numbers as usual.

Techirt has long discussed how in the modern era, the things you buy aren't actually the things you buy. And the things you own aren't actually the things you own. Things you thought you owned can be downgraded, bricked, or killed off entirely without much notice. That game console with backward compatibility? It no longer has backward compatibility. That smart home hub or smart speaker at the heart of your living room setup you've enjoyed for years? It not long works. The movies and books you thought were permanently in your personal catalog? Sorry, they aren't anymore. That perfectly good two-year-old phone? It no longer gets security updates, putting you and your data at risk.

This is all bad enough when talking about smart home hubs or smart refrigerators, but it's quite another thing entirely when it comes to medical implants. IEEE Spectrum has the Cory Doctorow-esque cautionary tale of Second Sight Medical Products whose Argus optical implants were commonly installed in patients in the early aughts to help them see. Accurately heralded as immeasurably innovative at the time, these devices may soon no longer work or be supported because the company that made them is going bankrupt:

"Terry Byland is the only person to have received this kind of implant in both eyes. He got the first-generation Argus I implant, made by the company Second Sight Medical Products, in his right eye in 2004 and the subsequent Argus II implant in his left 11 years later. He helped the company test the technology, spoke to the press movingly about his experiences, and even met Stevie Wonder at a conference. “[I] went from being just a person that was doing the testing to being a spokesman,” he remembers.

Yet in 2020, Byland had to find out secondhand that the company had abandoned the technology and was on the verge of going bankrupt. While his two-implant system is still working, he doesn’t know how long that will be the case. “As long as nothing goes wrong, I’m fine,” he says. “But if something does go wrong with it, well, I’m screwed. Because there’s no way of getting it fixed."

Users went from the miracle of suddenly being able to see their first Christmas tree, to the terror of the gift being taken away from them with absolutely no recourse. Not only that, the systems that were installed create new health complications if they're left installed but stop working, and are difficult to remove -- a cost that has to be eaten by the patients. The company's patients went from having their lives revolutionized by technology to, well, the opposite:

"These three patients, and more than 350 other blind people around the world with Second Sight’s implants in their eyes, find themselves in a world in which the technology that transformed their lives is just another obsolete gadget. One technical hiccup, one broken wire, and they lose their artificial vision, possibly forever."

It's quite the cautionary tale for the entire electroceutical sector, and those who assume the cutting edge technologies that help them today will stick around for tomorrow. It's one thing for your flip phone or Betamax player to become irrelevant, it's another thing for essential health devices embedded in your skull to simply stop working because their manufacturer couldn't keep their finances in order.