<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in reader</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>2f7dbd61 - PCC: remove proof-carrying code (for now?). (#12800)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/reader/#2f7dbd61</link>
        <description>PCC: remove proof-carrying code (for now?). (#12800)In late 2023, we built out an experimental feature calledProof-Carrying Code (PCC), where we attached &quot;facts&quot; to values in theCLIF IR and built verification of these facts after lowering tomachine instructions. We also added &quot;memory types&quot; describing layoutof memory and a &quot;checked&quot; flag on memory operations such that we couldverify that any checked memory operation accessed valid memory (asdefined by memory types attached to pointer values viafacts). Wasmtime&apos;s Cranelift backend then put appropriate memory typesand facts in its IR such that all accesses to memory (aspirationally)could be checked, taking the whole mid-end and lowering backend ofCranelift out of the trusted core that enforces SFI.This basically worked, at the time, for static memories; but never fordynamic memories, and then work on the feature lostprioritization (aka I had to work on other things) and I wasn&apos;t ableto complete it and put it in fuzzing/enable it as a production option.Unfortunately since then it has bit-rotted significantly -- as we addnew backend optimizations and instruction lowerings we haven&apos;t keptthe PCC framework up to date.Inspired by the discussion in #12497 I think it&apos;s time to deleteit (hopefully just &quot;for now&quot;?) unless/until we can build it again. Andwhen we do that, we should probably get it to the point of validatingrobust operation on all combinations of memory configurations beforemerging. (That implies a big experiment branch rather than a bunch ofeager PRs in-tree, but so it goes.) I still believe it is possible tobuild this (and I have ideas on how to do it!) but not right now.

            List of files:
            /wasmtime-44.0.1/cranelift/reader/src/parser.rs</description>
        <pubDate>Tue, 31 Mar 2026 04:00:00 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>f302ebd6 - Release Wasmtime 44.0.1 (#13241)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/reader/#f302ebd6</link>
        <description>Release Wasmtime 44.0.1 (#13241)[automatically-tag-and-release-this-commit]Co-authored-by: Wasmtime Publish &lt;wasmtime-publish@users.noreply.github.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/reader/Cargo.toml</description>
        <pubDate>Thu, 30 Apr 2026 15:00:00 +0000</pubDate>
        <dc:creator>wasmtime-publish &lt;59749941+wasmtime-publish@users.noreply.github.com&gt;</dc:creator>
    </item>
</channel>
</rss>
