<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>C on Prepakis Georgios | Kernelstub | Security Researcher</title><link>https://blog.kernelstub.dev/tags/c/</link><description>Recent content in C on Prepakis Georgios | Kernelstub | Security Researcher</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 21 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.kernelstub.dev/tags/c/index.xml" rel="self" type="application/rss+xml"/><item><title>Introduction to x64 ASM</title><link>https://blog.kernelstub.dev/posts/introduction-to-x64-asm/</link><pubDate>Sat, 21 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.kernelstub.dev/posts/introduction-to-x64-asm/</guid><description>&lt;h2 id="1-introduction-to-assembly-and-x64-architecture"&gt;1. Introduction to Assembly and x64 Architecture&lt;/h2&gt;
&lt;h3 id="what-is-assembly-language"&gt;What is Assembly Language?&lt;/h3&gt;
&lt;p&gt;Every program you&amp;rsquo;ve ever run, whether it&amp;rsquo;s a shell script, a Python interpreter, or a AAA game engine, eventually gets reduced to a stream of raw binary instructions that a CPU can execute directly. Assembly language is the thin, human-readable layer sitting right on top of that binary stream. Each assembly instruction maps almost one-to-one to a single machine instruction, so when you write &lt;code&gt;mov rax, rbx&lt;/code&gt;, you&amp;rsquo;re really just writing a mnemonic for a specific sequence of bits that tells the processor &amp;ldquo;copy the contents of one register into another.&amp;rdquo; There&amp;rsquo;s no compiler doing clever things behind your back, no garbage collector, no runtime. What you write is (almost) exactly what runs.&lt;/p&gt;</description></item><item><title>Advanced C Programming Best Practices</title><link>https://blog.kernelstub.dev/posts/advanced-c-programming-best-practices/</link><pubDate>Mon, 29 Jul 2024 00:00:00 +0000</pubDate><guid>https://blog.kernelstub.dev/posts/advanced-c-programming-best-practices/</guid><description>&lt;p&gt;C gives you almost nothing for free. There&amp;rsquo;s no garbage collector cleaning up after you, no runtime checking your array bounds, no exception handler catching your mistakes before they corrupt memory. That&amp;rsquo;s exactly why C is still the language of choice for operating systems, embedded firmware, and anything that needs to talk directly to hardware, and it&amp;rsquo;s also exactly why C code has such a long, embarrassing history of security vulnerabilities. The language trusts you completely. Most of &amp;ldquo;best practices in C&amp;rdquo; really boils down to one idea: build habits and guardrails that compensate for the safety net the language refuses to provide.&lt;/p&gt;</description></item></channel></rss>