<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Verification on TrustLang</title>
		<link>https://trust-lang.net/en/tags/verification/</link>
		<description>Recent content in Verification on TrustLang</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Wed, 09 Sep 2026 15:37:53 +0300</lastBuildDate>
		
			<atom:link href="https://trust-lang.net/en/tags/verification/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Guarantees and safety</title>
				<link>https://trust-lang.net/en/docs/safety/</link>
				<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
				<guid>https://trust-lang.net/en/docs/safety/</guid>
				<description>&lt;p&gt;This section brings together the &lt;em&gt;TrustLang&lt;/em&gt; capabilities that are responsible for the &lt;strong&gt;safety and&#xA;quality&lt;/strong&gt; of programs: safe memory management, protection from data races, correctness control at&#xA;compile time and formal verification.&lt;/p&gt;&#xA;&lt;p&gt;Each capability is described in detail &lt;strong&gt;in exactly one place&lt;/strong&gt; (the source page) and is only&#xA;mentioned here with a summary and a link. Detailed lists of options/diagnostics are not duplicated —&#xA;their source is the tool&amp;rsquo;s help (&lt;code&gt;trust --help&lt;/code&gt;, &lt;code&gt;trust -Whelp&lt;/code&gt;, LSP hovers).&lt;/p&gt;</description>
			</item>
			<item>
				<title>Status and plans</title>
				<link>https://trust-lang.net/en/docs/status/</link>
				<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
				<guid>https://trust-lang.net/en/docs/status/</guid>
				<description>&lt;h2 id=&#34;implemented-in-the-current-version-060&#34;&gt;Implemented in the current version (0.6.0)&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#implemented-in-the-current-version-060&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;&lt;input checked=&#34;&#34; disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; The &lt;a href=&#34;https://trust-lang.net/en/docs/syntax/concept/&#34;&gt;syntax concept&lt;/a&gt; has been developed&lt;/li&gt;&#xA;&lt;li&gt;&lt;input checked=&#34;&#34; disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; The &lt;a href=&#34;https://trust-lang.net/en/docs/syntax/macros/&#34;&gt;macro syntax&lt;/a&gt; has been defined&lt;/li&gt;&#xA;&lt;li&gt;&lt;input checked=&#34;&#34; disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; Parser and literals for &lt;a href=&#34;https://trust-lang.net/en/docs/types/&#34;&gt;basic data types&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;input checked=&#34;&#34; disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; The concept of &lt;a href=&#34;https://trust-lang.net/en/docs/safety/&#34;&gt;language guarantees&lt;/a&gt; has been formulated&lt;/li&gt;&#xA;&lt;li&gt;&lt;input checked=&#34;&#34; disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; The &lt;a href=&#34;https://trust-lang.net/en/docs/sandbox/&#34;&gt;playground&lt;/a&gt; for testing examples has been developed&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
			</item>
			<item>
				<title>Getting rid of Segmentation fault errors due to stack overflow in C&#43;&#43;</title>
				<link>https://trust-lang.net/en/blog/safety/stack-overflow/</link>
				<pubDate>Wed, 07 Jan 2026 00:00:00 +0000</pubDate>
				<guid>https://trust-lang.net/en/blog/safety/stack-overflow/</guid>
				<description>&lt;p&gt;January 7 at 14:53 2026&lt;/p&gt;&#xA;&lt;p&gt;Developing the idea of a &lt;a href=&#34;https://trust-lang.net/en/blog/safety/language-guarantees/&#34;&gt;trusted programming language&lt;/a&gt;, I came to the conclusion that, through restrictions of the syntax and the creation of corresponding checks in the static code analyzer, it is possible to protect against practically all technical errors except two — the control of dynamically allocated memory and stack overflow.&lt;/p&gt;&#xA;&lt;p&gt;Moreover, while solutions exist for reference counting at runtime, stack overflow control cannot be done not only during the analysis of the source text of the program, but it is practically impossible even during the execution of the application! After all, a stack overflow error is always fatal, since there is no way to catch and handle this error from inside the running program in order to then continue its execution as if nothing had happened.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Programming language guarantees as a basis for secure software development</title>
				<link>https://trust-lang.net/en/blog/safety/language-guarantees/</link>
				<pubDate>Mon, 10 Nov 2025 00:00:00 +0000</pubDate>
				<guid>https://trust-lang.net/en/blog/safety/language-guarantees/</guid>
				<description>&lt;p&gt;Errors in composing programs for computers appeared even earlier than the very first programming languages were invented. Actually, programming languages were invented precisely so that programs would be written more simply, and the number of errors in them would be as small as possible.&lt;/p&gt;&#xA;&lt;p&gt;To reduce the number of errors, many methods were developed, including the creation of specialized source code analysis tools and even entire programming languages.&lt;/p&gt;&#xA;&lt;p&gt;But after many decades, the problem of purely technical errors in software still remains unsolved to this day, however the approach proposed in the Rust language changes everything.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
