This week was quite busy in my code. Redarging my main application/product, I started to implement the database schema with sqflite in flutter. I did also a lot of tests regarding the flexibility of sqflite, and its potential limits in my use case. To be honest, I don't really like how this library is working but it should do the jobs for now. I also played with the flutter_quill text editor library (and also fleather). Not so complex to use, can produce something pretty cool quick. Finally, the BlocSignal pattern used in Flutter seems really attractive, lot of examples are available on their repository and it can be a good alternative of my approach (doing everything from scratch to learn).
It was not expected, but it looks like my motivation was focused to do C code for mac_randomizer. This is definitively a pet project, but C is still one of my favorite language, even if it can be challenging to do some things (e.g. concurrency), it's still great to do kinda low-level code. The source code tree is now clean, the Makefile is minimalist but should work on any system using GNU Makefile. Most of the functions are now sorted by categories in their own source file. The last action was to start working on a minimalist implementation of a Mealy machine, a specific kind of finite state machine, to parse mac addresses, instead of using an external regexp library. Actually, the implementation is a bit hard, not because of the complexity, but because of the interface and the abstraction. My idea is to have something like that:
// first tokenize the mac address to validate the
// characters used. Luckily, a mac address only has
// 23 allowed characters: [a-fA-F0-9\-\.\:]
//
// char *string is the raw strings containing the
// mac address.
//
// size_t length is the max size of the string, the
// tokenizer must stop when reading a NUL char or when
// it reaches the length limit
//
// the struct token *tokens is an array of token, where
// each token contains the raw valid character, the
// position of the character and the kind of token (e.g.
// digit, separator).
//
// the tokens should probably be defined inside another
// structure embedded the length of the array. This value
// should be incremented every time a valid character is
// found.
int
tokenizer(char *string, size_t length, struct token *tokens) {
return fsm_start(string, length, state, tokens);
}
// secondly, the parser will get the tokens and will convert
// them into an internal binary representation of the mac
// address (e.g. uint8_t mac_address[6]).
//
// The arguments of this function are similar to the previous
// one. The final result is then stored in the mac_address
// variable.
int
parser(struct token *tokens, size_t length, uint8_t *mac_address){
return fsm_start(tokens, length, state, mac_address);
}
// the question know is how to design correctly the fsm_start()
// function. It should have the possibility to deal with different
// kind of input, not only char, but also C data-structure. It
// should also be able to deal with different kind of output. Based
// on these requirements, the definition of the function should look
// like the snippet below.
//
// The input argument can be a problem here, at least for the
// mac address parsing feature. Indeed, a string representing a
// mac address only has a few format, with specific length:
//
// EUI48-IEEE: xx-xx-xx-xx-xx-xx (max length 17)
// EUI48-IETF: xx:xx:xx:xx:xx:xx (max length 17)
// EUI48-CISCO: xxxx.xxxx.xxxx (max length 16)
// EUI64-IEEE: xx-xx-xx-xx-xx-xx-xx-xx (max length 23)
// EUI64-IETF: xx:xx:xx:xx:xx:xx:xx:xx (max length 23)
//
// the input string should then have a maximal value of 23
// (+1 with NUL), and a minimal value of 17(+1 with NUL). The
// output can also be limited to sizeof(uint8_t)*6=48bits or
// sizeof(uint8_t)*8=64bits. Using the 64bits version is perhaps
// the best choice because an EUI48 can be converted to an EUI64
// and vice versa. Note: I don't even think it's possible to
// compress this value, it will probably add more complexity
// for no real benefits on the long run.
int
fsm_start(
void *input,
size_t input_length,
void *output,
struct state *init
){
// do something here.
}
// the states must also be defined somewhere. states can
// be created dynamically by instantiating different kind
// of object and pushing them together, or creating them
// "statically" in their own data-structure with their
// own callback functions. One of the idea is to create
// something like the code below.
//
// The handler_enter callback is called only when a transition
// occurs between states.
//
// The handler_input callback is executed when an input
// is received.
struct state {
struct state*(handler_enter)(struct state *s);
struct state*(handler_input)(void *input, void *output, struct state *s);
};
As you can see, it's a good mental exercise to find the right way to implement something like that in C. In fact, a mealy (or moore) FSM are being use with Regexp but also with other complex protocols like TCP. Reimplementing something like that to parse well specified data like a mac address is probably the best choice, and, if correctly done, it could also be used to encode as well.
Anyway, here some implementations from github:
More implementation examples can be also found in userland from OpenBSD, FreeBSD and NetBSD projects. Many of those tools can have an implementation of a finite state machine.
- OpenBSD:
-
usr.bin/patch/ed.c: it contains a small finite state machine implementation used to parse commands games/bs/bs.cusr.sbin/npppd/npppd/fsm.cusr.sbin/pppd/fsm.clib/libc/gen/unvis.c
-
- FreeBSD:
- NetBSD:
Most of my posts are currently stuck in draft mode due to that, but I like the weekly review format. It is a good summary containing a lot of information in one place. Then, I think most of the coming publications will use this format.
Coding
π A deep dive into HEEx compilation from LiveView 1.2: A post explaining the foundation of the HEEx template systems present in Phoenix LiveView. I did not know it was tokenized. In fact, this is a very good news... It is becoming closer to the way clojure is dealing with HTML.
π an application in lisp you grow by talking to it: LISP is probably one of the greatest language of all time, in this article, the program is created by talking to an LLM during a coding session.
ποΈ WeaveC: A C compiler with inferred ownership and borrow checking for Rust-style memory safety.
π Tools for your Elixir app: A starting point for each kind of application. Recommended tools, why we use them, and when to choose something else.
ποΈ cccc: measures Cognitive Complexity (SonarSource / G. Ann Campbell) and Cyclomatic Complexity (McCabe). I used similar tools in the past, like ccc and scc or sccc. Nice to have, even before if you add it in your CI/CD to evaluate the complexity of a commit.
π Reducing undefined behavior in the C language: undefined behavior in C is a nightmare. Probably one of the most complex part of the language, and it can lead to total disaster. This post is presenting the solution to avoid common mistakes and find a way to create safer C code. Actually, this is from a talk, and the slides are available online.
π What Every C Programmer Should Know About Undefined Behavior #1/3: the first article of a series about undefined behavior in C.
π Abstract Syntax Tree, An Example in C: a short publication with nice example to explain how to implement and use an AST.
π One-pass Compiler: a nice trick to compile code directly without passed inside different layer.
π Compiling to Assembly from Scratch: a book by the author of the two previous posts. neat.
π CASM: Implementing an Abstract State Machine based Programming Language
System
π Headers Up! What's New in httpd and relayd: HTTP header manipulation support and request filtering. I'm still using nginx, but httpd is becoming really better every new release.
π Locking down openat(2) and friends with O_BELOW and F_BELOW: a mail-exchange describing the (future?) openat function to open file with relative path (and more safety).
ποΈ scrcpy: Display and control your Android device.
ποΈ floci: gives you AWS-shaped services on your machine without requiring a cloud account, an auth token, or paid feature gates.
ποΈ riscv/learn: A community-driven, continuously updated compilation of RISC-V learning resources. Content is organized by topic and experience level to help you discover courses, software, documentation, and articles efficiently.
π Haskell: The Craft of Functional Programming: revised version.
ποΈ DPDK (Data Plane Development Kit): an open source framework for fast packet processing on standard hardware. It runs in cloud infrastructure, telecom networks, financial exchanges, particle accelerators, and radio telescopes. Most of your traffic already runs through it. Start by reviewing a patch, no account or setup required. I discovered it was also running not only on Linux... I need to try that.
π unikernels were hard. key word: were: unikernel IS THE WAY TO GO, but I still this a complex technology mixing a lot of features from many different part of any systems. In fact, this is really close to microkernel, and both are, to me, two things that should be merged together.
Network
ποΈ Open vSwitch (OVS): a production quality, multilayer virtual switch, designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols.
ποΈ Open Virtual Network: a series of daemons for the Open vSwitch that translate virtual network configurations into OpenFlow.
Database
ποΈ Awesome Database Learning
ποΈ pgvector: Open-source vector similarity search for Postgres
Security
π Malicious Flutter Package while it have a Clean Code?: malware present in example directory inside a flutter project. Don't trust blindly all projects.
π How to fix a bug in a fix
π Chrome's Response to Recent ccTLD Registry Hijacks: Following recent .gh, .sl, and .as ccTLD domain hijacks, Chrome immediately blocked unauthorized HTTPS certificates via CRLSets to protect users automatically.
Telegram Desktop: one-click account takeover via IPC injection: a post describing the CVE-2026-107181, where one malicious actor can take control of a group by sharing a telegram link and opening it on the telegram desktop application. The problem is from the URI parser, when dealing with semicolons. That's an interesting attack, because many application can be ported on different systems, like Signal or SimpleXChat, and depending of the languages/tools used, some part of the can use different routines.
Security/Cryptography
π SequenceHash: multihashing for the rest of us
π Hash Smash: Find ordinary collision attacks that reach more rounds with less total computation. Select a hash functionβs chart, then one of its two round counts.
π MiniSHAKE: an extendable output function based on Keccak, with unlimited size output.
π TurboSHAKE: an extendable output function based on Keccak, with less rounds to improve performance.
π Key Length: The minimum key sizes each source publishes for protecting data until a given year.
Embedded
ποΈ CPU Performance Engineering: A reading path for CPU performance engineering, from one instruction to production inference. Primary sources only, with a runnable benchmark for every section.
π The FPGA Chronicles: Open Source It
ποΈ PasRISCV:A RISC-V RV64GCV/RVA23 emulator written in Object Pascal. It simulates processor cores, memory, I/O, and much more.
Update/Upgrade
π hackney 4.8.5: bug fixes.
π Cowboy 2.20: security and bug fixes.
π LibreSSL 4.2.2 and 4.3.3: security and bug fixes.
Computer Science
π Digital Hardware Design DFA, Mealy and Moore Machines: a lecture on Mealy/Moore machines
π A Report on Achieving Complete Regular-Expression Matching using Mealy Machines: an interesting (but complex) publication about regexp and finite state machine to match exact pattern.
π Effective Reductions of Mealy Machines: reducing mealy machines states and transitions.
Misc
π The empty brain: an amazing post about brain information processing. The brain is not storing information like a computer (a stream of bits), and in fact, it is not the only organ to "store it". It stores experiences, and experiences are different between every people alive, then, it will be impossible to "copy" experiences between humans. In fact, like the author is explaining in his publication, even if all neurons' states were extracted, copied and connected together, it will have no meaning because it would be outside of the body where the experiences have been learned.
Because the Information Processing metaphor is not even slightly valid, we will never have to worry about a human mind going amok in cyberspace; alas, we will also never achieve immortality through downloading. [...] We are organisms, not computers.
π Victime dβune fuite de donnΓ©es ? Voici dans quels cas vous pouvez rΓ©clamer une indemnisation: see also that on the CNIL website
π A strategist who called the Asian financial crisis sees parallels with the AI boom: another indicator the "AI" boom is not really doing what every one expect. I wanted to read The Myth Of AI's Miracle: Albert Edwards Spots The Same Fatal Flaw That Sank Asia In 1997, but, well, it is a premium article.
the productivity payoff from AI remains a forecast, rather than an observation [...] No AI productivity boost in the data yet [...] too many people believed the beguiling narrative and as a consequence, lent these economies cheap, abundant capital which was misallocated.
π¦ THE SIGNS THAT THE AI BOOM IS BUILT ON FAKE REVENUE ARE NOW HERE. Here is what is really happening: a thread about what could happen with the AI financial - SCAM - scheme. Anyway, it smells really bad, even worse than the crypto-currency bubble.
Every time an AI startup raises money at a higher valuation, the investor raises the value of its stake on its books and counts the increase as income. No cash comes in. The profit is on paper. [...] A large part of the sales and profits these companies report depends on money that investors, including the tech giants themselves, keep putting into OpenAI and Anthropic. If that funding slows, the backlog, the sales and the paper profits all weaken together.
Leaks of the week
π¦ Tata Consultancy Services: source code and credentials leaked.
π¦ UAE government: 17 millions entries from UAE government-related software licensing database
π¦ Get covered: more than 1 million customer records including email, phone numbers, physical address and more.
π¦ CAPEB: Around 4 millions records including emails and phone numbers.
π¦ Denmark government: 8.8 millions people impacted, Danish citizens and emigrates. The leak include Social security number, Age, Sex, Family relations, Physical address, Protected addresses and Sex change.
Cover Image by Alfred Schrock on Unsplash















Top comments (0)