I want to point out an implemented feature that people SHOULD be adopting but that I doubt will be picked up:

  P2590R2, Explicit lifetime management (PR106658)

This is for "std::start_lifetime_as<T>". If you have not heard of this before, it's the non-UB way to type-pun a pointer into a structured type.

Nearly all zero-copy code that deals with external I/O buffers looks something like:

  std::unique_ptr<char[]> buffer = stream->read();
  if (buffer[0] == FOO)
    processFoo(reinterpret_cast<Foo*>(buffer.get())); // undefined behavior
  else
    processBar(reinterpret_cast<Bar*>(buffer.get())); // undefined behaviour

With this merged, swap the reinterpret_cast for start_lifetime_as and you're no longer being naughty.

https://en.cppreference.com/cpp/memory/start_lifetime_as

There was already a legal way to achieve this that everyone should already have been using (laundering a pointer through a no-op memmove). Using reinterpret_cast here is a bug.

The "start_lifetime_as" facility does one additional thing beyond providing a tidy standard name for the memory laundering incantation. Semantically it doesn't touch the memory whereas the no-op memmove intrinsically does. In practice, this makes little difference, since the compiler could see that the memmove was a no-op and optimized accordingly.

This still has unresolved alignment issues that blow up outside the amd64 ecosystem.

Is this just a basic lack of alignment enforcement or is there a bigger issue?

No because the object does not exist after std::launder. It only exists after std::start_lifetime_as. The bytes being there says nothing about the object, per the C++ standard.

The compiler will create an implicit lifetime type at the memmove destination as required to give it defined behavior. Technically you don't even need std::launder, it is just far more convenient than the alternative.

The cppreference description seems questionable to me:

> Implicitly creates a complete object of type T (whose address is p) and objects nested within it. The value of each created object obj of TriviallyCopyable type U is determined in the same manner as for a call to std::bit_cast<U>(E) except that the storage is not actually accessed, where E is the lvalue of type U denoting obj. Otherwise, the values of such created objects are unspecified.

So T is the complete new object. It contains subobjects, and one of those subobjects has type U. U is initialized as if by bit_cast, and I presume they meant to say that bit_cast casted from the bits already present at the address in question. Since “obj” is mentioned without any definition of any sort, I’ll assume it means something at the correct address.

But what’s E? The page says “E is the lvalue of type U denoting obj,” but obj probably has type char or a similar type, and if it already had type U, there would be no need for bit_cast.

Well, ignoring alignment restrictions, it depends on the implementation of read. If it is truly opaque, as far as the compiler is concerned, the kernel (or the network card or whatever) is truly constructing a Foo in that buffer, making the cast perfectly legitimate.

start_lifetime_as is useful when the buffer lifetime is transparent to the compiler and it can mess up aliasing assumptions.

Your code is not only naughty, it’s also incorrect due to alignment issues.

You’re allowed to type pun char buffers.

No, you're not.

You're allowed to access any type via a char buffer. But the converse is not true (quoting https://eel.is/c++draft/expr#basic.lval-11):

> An object of dynamic type Tobj is type-accessible through a glvalue of type Tref if Tref is similar ([conv.qual]) to: Tobj, a type that is the signed or unsigned type corresponding to Tobj, or a char, unsigned char, or std :: byte type. If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.

The dynamic type of a char buffer is, well, a char buffer, and can only be accessed via things that are the same type as a char buffer up to signedness and cv-qualification. The actual strict aliasing rules are not commutative!

I’m not a language lawyer but i think the part you are missing is about “type establishment”. (Is this a C vs C++ thing?)

Malloc returns a buffer and then you cast it to the type you want. Similarly for all memory allocators.

Punning the same region of char buffer as two different types is a bit different.

This gets to the heart of effective type rules, which are complex, confusing, and not properly implemented by compilers. C and C++ definitely diverge here, because C is less ambitious in its object model (which mean it just simply leaves so many details about it undiscussed).

Malloc returns memory that is uninitialized and has no type. The effective type of that memory is initialized on first use by C, whereas C++ relies on angelic nondeterminism to magically initialize the type at return type to whatever will work in the future.

> Malloc returns a buffer and then you cast it to the type you want.

You can’t cast the buffer — you’re casting the pointer.

One might argue (I’m not sure whether this is correct) that malloc allocated an array of ints and the language merely has no way to state that directly. Then you write to those ints using a char pointer, and then you access them as ints, but they’ve been ints ever since allocation.

yes but that works not because malloc is special but because there are more relaxed types rules than suggested by the comment above.

If the type is an implicit-lifetime type, then you can legally create an unsigned char array, and then reinterpret_cast a pointer to that to a pointer to the type.

See https://eel.is/c++draft/intro.object#def:object,implicit_cre....

https://eel.is/c++draft/intro.object#15 is an example showing this with malloc; the subsequent paragraph further permits it to work with an unsigned char array.

1. You still need std::launder in that case.

2. It doesn't initialize the object that is implicitly created, even if the storage has initialized chars.

The paper that introduced the implicit lifetime mechanism suggests that std::launder is not required: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p05....

And should always use -fno-strict-aliasing anyways. The default rules are insane

It's really cool to see that other people run into the same issues and arrive at the same conclusions/solution.

At $DAYJOB, we have an LLM-based tool and this issue of "how do we avoid burning tokens solving the same problems over again" was an early obstacle

We wound up building a very similar thing to what you call "tools" (we named them "Saved Programs").

There's a wiki the LLM searches before solving a problem, that links saved programs for past actions to their content entry.

If it finds one, it'll re-use it, otherwise it'll generate a program and offer to save it, if you think it'll be common enough.

> how do we avoid burning tokens solving the same problems over again

Letting the LLM write half baked tools is the recipe for burning more tokens.

> There's a wiki the LLM searches before solving a problem, that links saved programs for past actions to their content entry.

What's the criteria for marking an LLM written tool as useful/correct before publishing it?

  > Letting the LLM write half baked tools is the recipe for burning more tokens.

It sure is, if the tools are half-baked and your user scale is N=1 rather than N=100 or N=1,000

  > What's the criteria for marking an LLM written tool as useful/correct before publishing it?

It solves the problem the originating user asked it to

> It solves the problem the originating user asked it to

Interesting. And is there a mechanism to go back and "fix" the tools after they are published? What happens if the tool decided to use the "id" attribute to click on buttons and now you have a new website that follows a different pattern to find the right target?

I agree that "correctness" of a tool could have different meaning depending on the context of the problem though (e.g. would you consider OOM a correctness bug even if it addresses the user's ask?)

The problem here is that N different users will ask for N different variants of the same tool, so you'll end up with a tool which is similar but not quite. Is the tool updated to support new functionality, or a new tool is created and you end up with N variants of a tool.

it's called workflow automation: https://blog.codesolvent.com/2025/12/workflow-automation-let...

Everyone is just taking a round about way to get there. The workflow/program as "tools" approach is the right one. Agents skills are more or less in that same direction.

there are hundreds or thousands of 'memory' things ppl have been inventing. i am yet to see any proof that these are actually useful or have saved any tokens.

Yes

Crackpot "Universal Theory of Everything" physics rooted in numerology:

https://meta-r0ze.github.io/Informational-Energetics/Informa...

Do you all want to know a fun fact about adult-content startups:

Why do you think Onlyfans is the reigning platform for what it does.

Not because it's technically superior, or has the best advertising, or any other logical reason you might summon.

It's because they have a sweetheart deal with a payment processor (Stripe).

I put some time into seriously investigating what it'd take to get an adult-content platform off of the ground, here is one of the emails I received from a self-advertised "high-risk processor":

  > "Yes, we do have some Payment Facilitator solutions. However, none of these processors will accept Adult content."

Nobody will touch it with a 10 foot pole. It's absolute bullshit and is ripe for disruption.

Unironically, very niche subreddits.

I had mentioned the same thing on Twitter and the author replied, FYI:

https://x.com/GavinRayDev/status/2047024420200522129

My grandfather told me that for Christmas one year as a child, he got a fresh orange.

Only one year? And was that his only gift?

My sister and I received fresh oranges in our Christmas stockings every year. Along with nuts and chocolate and goodies like that. Of course, the "Christmas stocking" event was tied with St. Nicholas' Day on December 6, where it was traditional to place our shoes on the fireplace overnight, but the stockings were stretchy and higher-capacity than children's shoes!

Also, the fresh oranges were sort of ironic, because a tangerine tree grew in our backyard. I've always preferred tangerines.

Mom always packed fresh fruit with my school lunches. I had never heard or experienced the trading of food at lunch, and so I resorted to discarding the parts of lunch which I didn't want to eat. Oranges were the first to go. It wasn't the taste of oranges that I disliked, it was the stickiness and the labor involved in peeling them and getting past the rind and pith.

>Only one year? And was that his only gift?

Really depends on the year and the region. Cheap oranges can only follow where the reefer truck and boxcar go.

At promptql, our solution to this was a wiki. You get knowledge-graph/relations for free through page links.

New knowledge additions are proposed when agents decide it would be relevant to retain, humans confirm/deny or create wiki modifications themselves.

Biologics production is one of the industries that is ripe for a manufacturing breakthrough, and would greatly benefit humanity.

The current best option we have for combating heart disease and lowering cholesterol are monoclonal antibodies (PCSK9 inhibitors), and a similar trajectory is developing with sarcopenia and obesity biologics (Bimagrumab).

Manufacturability is treated as an afterthought right now, but as we’ve seen in other industries, if you can bring some of those constraints earlier into the process it can have serious economic implications.

The opportunity for manufacturing innovation is growing, as the next generation of monoclonal antibodies are even more difficult to produce at scale.