ABlockInTheChain

I recently learned that both clang and gcc have added support for N3017 a.k.a #embed from C23 so naturally my first reaction was to see how well it works in C++ code.

Given this code sample:

#include <array>
#include <cstdint>
#include <experimental/array>
#include <iostream>
#include <utility>

int main() {
    // works
    static constexpr char c_char_array[] = {
        #embed __FILE__
        , '\0'
    };
    static constexpr unsigned char c_unsigned_char_array[] = {
        #embed __FILE__
        , '\0'
    };
    static constexpr std::uint8_t c_uint8_array[] =

I just got done reading today's cppfront update while some recent discussions about ABI were still on my mind, and that resulted in the following idea:

Why not define a new platform for which no existing software exists, but to which existing software could be easily ported? This would provide the freedom to make many desirable changes without worrying about breaking anything.

The ideal testbed for this experiment would be on Linux, because of the availability of source code ease of spinning up a "minimum viable operating system", consisting solely of a kernel image with an embedded initramfs which runs busybox. That's all you need to boot to a command line.

Linux also already supports mu

Recently I've been working on a use case which I thought should be supported by presets: write a CMakePresets.json file which can be added to a cross platform project to make it easy for all members of a team, not all of which are experienced in configuring build environments, to easily compile the project.

What I actually found is that this is not a good use of presets because many features are almost capable of achieving the desired functionality but are missing some critical piece to make them actually usable. This is quite unfortunate because presets are very close to solving this problem while still falling short.

Here is a sample of issues that are holding us back and the missing p

A pattern I've been taking advantage of since scoped enums were added is the ability to put opaque enum declarations in one header and the full definition in another header because it's more common to only need the size of the enum than it is to need to know any of the actual enumerators.

The main advantage of doing that is it is possible to add new enumerators without unnecessary recompilation. A translation unit that contains a function definition that accepts an enum type as an argument and simply passes to another function should not need to be recompiled if the type simply gained a new enumerator and this is easily accomplished with headers and opaque declarations.

Is this behavior po

diff --git a/src/consensus/consensus.h b/src/consensus/consensus.h
index 351911a..ef56709 100644
--- a/src/consensus/consensus.h
+++ b/src/consensus/consensus.h
@@ -13,7 +13,7 @@ static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
 /** The maximum allowed weight for a block, see BIP 141 (network rule) */
 static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
 /** The maximum allowed size for a block excluding witness data, in bytes (network rule) */
-static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000;
+static const unsigned int MAX_BLOCK_BASE_SIZE = 4000000;
 /** The maximum allowed number of signature check operations in a block (n

Recently I was asked about what a hard fork alternative to segwit would look like, and although I know this has been discussed in various venues, I couldn't find a single writeup anywhere.

Problem

There are two general use cases that require a transaction to have a name of some kind:

• Merkle tree: In order to prove an exact form of a transaction was included in a specific block, the transaction's hash is used to create a Merkle tree
• Transaction inputs: Normal transactions spend existing outputs and so need to reference a unique transaction identifier that unambiguously maps to a previously-mined transaction.

Bitcoin currently uses the transaction hash as the transaction identifier

Pre 2013

Bitcoin users and developers have near universal agreement that the block size limit is a temporary feature must be raised and/or removed. Preparing for this hard fork is one of lead developer Gavin's top priorities.

https://web.archive.org/web/20140328052630/https://en.bitcoin.it/wiki/Talk:Scalability

MAX_BLOCK_SIZE has always been planned to increase as needed. That limitation should be ignored. theymos 17:15, 4 March 2011 (GMT)

What Theymos said. Increasing MAX_BLOCK_SIZE will be done when "lightweight, header-only" client mode is done. Until then, block size has to be kept under control.--Gavin Andresen 00:19, 5 March 2011 (GMT)

However development priorities a