The fixed size int types int32_t and friends weren't introduced until C99. Microsoft held out until 2013 before it put <inttypes.h> into Visual Studio!
So there has been a really long time in C's evolution where we haven't had fixed size types which has been a super annoying mess of #ifdefs in portable code.
The variable size ints have allowed some super weird architectures though. I remember looking at the datasheet for the Motorola 56000 DSP and noting that the C compiler set char = short = int = 24 bits! That was because the hardware could not address anything smaller than 24 bits. I think long could be 48 bits.
The product is named Visual C++, that it happened to do C was always kind of a sideshow as far as I could tell. Aside from that, I seem to recall that VC++ had the WORD, DWORD, and eventually QWORD macros to specify unsigned 16, 32 and 64 bit types respectively.
And their names are so frustrating. We don't run 16 bit systems any more. Word is a word that means something and I don't care what a word was on the 8086. The only honest things the WORD macro could expand to are size_t and ssize_t. 64bit is not a quad word, it's just a word.
I find Microsoft method of naming every type with a pointer a major annoyance. This is one reason I find reading non-Windows C applications easier.
Give me `int*` vs `PINT`. Microsoft really likes to over engineer causing you have to pointlessly remember more.
The worst is when they redefine the same structure or union under a different name. Example: `IP_ADAPTER_ANYCAST_ADDRESS_XP` is the exact same as `IP_ADAPTER_MULTICAST_ADDRESS_XP`.
I know pi to 50 places learned through lots of repetition. I've always been good at remembering numbers though.
I don't find the memory palace tricks helpful at all though. I think that is a consequence of my Aphantasia and something I only realised recently. I can't visualise a memory palace so placing things in it is impossible!
Is there "benchmark data" on different memory techniques? I also wondered about this because I also memorized 50 digits on a lark back in high school, without the post's encoding technique and memory palace.
I added one block of 10 digits per night, spending maybe 10 minutes per night? Very roughly an hour total, ~same as the poster spent to get 100 digits, but without the prior investment they spent on the PAO (memorizing 300 key-value pairs, apparently).
I’m on the complete opposite part of the spectrum from aphantasia, but also don’t find the memory palace concept useful. Actually, I find any trick to memorize things to be a detriment to actually remembering things effectively! I still have to go through the whole alphabet song, instead of having the order internalized :)
On the other hand I learned 15 decimals of pi as a kid through pure rot training and feel they are way more internalized
I used sdcc for an 8051 based commercial project a while back. I seem to remember spending more time reading the assembly to figure out workarounds for the compiler than actually writing C code!
Whereas sdcc works brilliantly for z80 lineage processors. I wrote quite a lot of C for Gameboy recently and didn't find a single compiler bug in sdcc which revised my opinion of it upwards greatly.
I don’t know how fast it is but that does not really follow. They added those instructions so that Linux would boot. Linux assumes Pentium and no longer boots on 386 or even 486 for the latest kernels.
The presence of instructions first added in the Pentium really does not tell you anything about performance.
Guess technically true absolutely; I gotta admit I assumed they wouldn't bother implementing the instruction sets unless there was functional, i.e. prospect of reasonable speed, aspect to it.
This describes my life as an open source maintainer at the moment!
In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month! That has taken a huge amount of my time, even using AI tools to triage and come up with fixes for review.
The hit rate for those security disclosures is pretty good - about 75% of them have a nugget of something which needs looking at. The configurations for rclone have got increasingly unlikely so I'm hoping they will dry up eventually.
I was considering just merging the fixes straight to master just to make my life easier rather than holding a dozen independent security fixes on branches and merging them at the point release and hoping not to have too many conflicts to fix up. I've decided to stick with the process for the moment.
GitHub assigns CVEs for the advisories. Before the AI apocalypse they took 2-3 days for an assignment but now it they are running at 3-4 weeks so I have to send the point releases out with CVE-PENDING in the changelog which isn't ideal.
Not sure what the solution is, but it is definitely a problem for us.
I came across rclone at work because "Copy or move data to Azure Storage by using AzCopy v10" is a lie, it literally can't `move` files, only `copy` them.
I can't express in polite words how pathetic it is to see the only official blob storage bulk transfer CLI tool from a multi-trillion-dollar company fail to do the simplest, most essential functionality after ten major revisions.
Right? If you move between file system or device I would expect "move" to be impossible. At best you could copy a logical block and then delete a logical block. If you share a filesystem then perhaps a logical block is a few hundred kilobytes. If you don't then I'd expect the smallest logical block to be the file itself.
Right! When I wrote that I made a mistake and thought that there were filesystems that used multiple drives but still had the meaningful distinction of "what drive is that file on?"
Like, yeah, RAID, several drives, one filesystem, right? Except no, because it's just one virtual device.
I can’t comment on if it applies to your workflow, but one process I’ve used is to aggregate and land ~10 security patches at a time. Eg,
- grab a group of (related) bugs/defects/vulns
- fix them on a branch like bug-batch-XXX
- run that group through the verification, landing in main, CI/CD flow to amortize process cost
- repeat as needed to process backlog
My experience is that process often has irreducible time (eg, two days due to reviews by various parties); but that time slot can be shared between several bugs in a single PR — especially if you have several related to the same feature.
Possibly some sort of ai agent code review system that churns through code looking for these vulns before the code is published. It feels like it's all about who has the resources to find bugs at the moment but that it should be a standard to catch issues before prod moving forward..
Yea, AI bug finding over entire projects, at least on SOTA models is super expensive, hence those with the resources setup to find the most bugs in an automated way.
That said there are a number of people and companies working on more focused means of driving the LLM to look were bugs would be the most dangerous and in doing so reduce the token spend of each bug found.
In some ways the better you are at security stuff the more you can reduce your spend by better driving the LLM to problem spots.
Same with some of the projects I maintain. The reports came in for one project over a few months and then once those dried up, and they did become increasingly unlikely or appear to be edge cases, the reports started to accumulate for another project.
Great to get these issues addressed but it's exhausting.
I feel like someone somewhere is working on an opensource GPU compute resource pool you guys could pull from as part of a donation type framework. I got a bunch of local gpu resources just relaxing, and if I could load up a a binary to provide compute for X hours a day overnight or whatever, that'd be cool.
http://github.com/buzz/block is quickly becoming a reasonable approach to shared agent compute, though it's still a bit more hands-on than the older 'compute donation' projects like SETI or Folding@Home.
> GitHub assigns CVEs for the advisories. Before the AI apocalypse they took 2-3 days for an assignment but now it they are running at 3-4 weeks so I have to send the point releases out with CVE-PENDING in the changelog which isn't ideal.
A strange bottleneck; anyone know why that would be so slow?
As mentioned by another commenter, they intentionally have a human reviewer in the process before a GitHub Security Advisory (GHSA) becomes "official" post-publish
(this is separate to getting CVE ID assigned, if wanted)
Thank you for the insight! Are you going back to the changelog and editing the CVE-PENDING? I think this would be a justifiable edit of the release history that I'm not sure is possible on github.
You can add CVE info later in a git note, if you want something git-managed to point to it. Might take some habit-tweaking to include notes in log output though, to see them later.
I was looking at the reed Solomon implementation. I've done a few of those in the past! I note that you are using logs for multiplication. I always used to use a 64kb table for direct lookup, though maybe that isn't faster on modern processors?
Interesting. I'll have to give it a try. If I understand your suggestion, you're saying that rather than doing 2 lookups for logs, then an addition, and then another lookup to exp back, we could just precompute the whole thing for any 2 arguments and do one lookup in a table? It's worth noting that some of the operations already use the mul_log format which just does an add with wraparound, but I could certainly see the big table option helping when we truly need field.mul
As far as LDPC, I'd love to, but I need to get a better understanding of them first. I'll probably go for Turbo next just because conceptually they feel closer to the convolutional codes I have already. But time willing, it'd be fun to do both.
I used and developed software for RISC OS for many years and it was there I cut my teeth as an open source developer.
I wrote the very popular !Director application which let you customize your Desktop and add lots of nifty shortcuts. It could be expanded with BASIC plugins to do just about anything! It was distributed by the Arcade BBS to start with then Acorn User magazine put it on the floppy disk that came with the magazine.
Amazingly Director was written entirely in ARM assembler (with the help of lots of macros). I used to really enjoy writing ARM assembler and used to grit my teeth whenever I had to read the assembly output of the C compiler! I remember writing quicksort in ARM assembler as part of this (to sort menu entries) which was a lot of fun.
I still have a RiscPC under my desk, but I don't think I've turned it on for nearly 15 years :-(
32bit ARM remains my absolute favorite instruction set. And yeah, C compiler output was criminal! I wrote products entirely in the BASIC assembler. What a time to grow up!
I went down a rabbit hole a few summers ago and I ended up writing a calculator from scratch in assembly for RISC OS. Interesting experience having GUI routines at the syscall level
I have a RiscPC in the shed and a half-repaired A3000. I don't fire them up them often, but both have !Director launching on boot; it is a wonderful program. Thanks!
https://youtu.be/e1bPfbNn_TU?is=zrTGCKm_6klH0JwZ
reply