Breaking Type Safety in Go: An Empirical Study on the Usage of the unsafe Package

• URL: http://arxiv.org/abs/2006.09973v4
• Date: Thu, 22 Jul 2021 18:51:48 GMT
• Title: Breaking Type Safety in Go: An Empirical Study on the Usage of the unsafe Package
• Authors: Diego Elias Costa, Suhaib Mujahid, Rabe Abdalkareem, Emad Shihab
• Abstract summary: We present the first large-scale study on the usage of the unsafe package in 2,438 popular Go projects. Our investigation shows that unsafe is used in 24% of Go projects, motivated primarily by communicating with operating systems and C code. We report a series of real issues faced by projects that use unsafe, from crashing errors and non-deterministic behavior to having their deployment restricted.
• Score: 3.548075273599941
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: A decade after its first release, the Go programming language has become a major programming language in the development landscape. While praised for its clean syntax and C-like performance, Go also contains a strong static type-system that prevents arbitrary type casting and arbitrary memory access, making the language type-safe by design. However, to give developers the possibility of implementing low-level code, Go ships with a special package called unsafe that offers developers a way around the type-safety of Go programs. The package gives greater flexibility to developers but comes at a higher risk of runtime errors, chances of non-portability, and the loss of compatibility guarantees for future versions of Go. In this paper, we present the first large-scale study on the usage of the unsafe package in 2,438 popular Go projects. Our investigation shows that unsafe is used in 24% of Go projects, motivated primarily by communicating with operating systems and C code, but is also commonly used as a source of performance optimization. Developers are willing to use unsafe to break language specifications (e.g., string immutability) for better performance and 6% of analyzed projects that use unsafe perform risky pointer conversions that can lead to program crashes and unexpected behavior. Furthermore, we report a series of real issues faced by projects that use unsafe, from crashing errors and non-deterministic behavior to having their deployment restricted from certain popular environments. Our findings can be used to understand how and why developers break type-safety in Go, and help motivate further tools and language development that could make the usage of unsafe in Go even safer.

Related papers

• Decompiling Smart Contracts with a Large Language Model [51.49197239479266]
  Despite Etherscan's 78,047,845 smart contracts deployed on (as of May 26, 2025), a mere 767,520 ( 1%) are open source.<n>This opacity necessitates the automated semantic analysis of on-chain smart contract bytecode.<n>We introduce a pioneering decompilation pipeline that transforms bytecode into human-readable and semantically faithful Solidity code.
  arXiv  Detail & Related papers  (2025-06-24T13:42:59Z)
• Exposing Go's Hidden Bugs: A Novel Concolic Framework [2.676686591720132]
  We present Zorya, a novel methodology to evaluate Go programs comprehensively.<n>By systematically exploring execution paths to uncover vulnerabilities beyond conventional testing, symbolic execution offers distinct advantages.<n>Our solution employs Ghidra's P-Code as an intermediate representation (IR)
  arXiv  Detail & Related papers  (2025-05-26T16:26:20Z)
• Targeted Fuzzing for Unsafe Rust Code: Leveraging Selective Instrumentation [3.6968220664227633]
  Rust is a promising programming language that focuses on usability and security.<n>It allows programmers to write unsafe code which is not subject to the strict Rust security policy.<n>We present an automated approach to detect unsafe and safe code components to decide which parts of the program a fuzzer should focus on.
  arXiv  Detail & Related papers  (2025-05-05T08:48:42Z)
• CRUST-Bench: A Comprehensive Benchmark for C-to-safe-Rust Transpilation [63.23120252801889]
  CRUST-Bench is a dataset of 100 C repositories, each paired with manually-written interfaces in safe Rust as well as test cases. We evaluate state-of-the-art large language models (LLMs) on this task and find that safe and idiomatic Rust generation is still a challenging problem. The best performing model, OpenAI o1, is able to solve only 15 tasks in a single-shot setting.
  arXiv  Detail & Related papers  (2025-04-21T17:33:33Z)
• ReF Decompile: Relabeling and Function Call Enhanced Decompile [50.86228893636785]
  The goal of decompilation is to convert compiled low-level code (e.g., assembly code) back into high-level programming languages. This task supports various reverse engineering applications, such as vulnerability identification, malware analysis, and legacy software migration.
  arXiv  Detail & Related papers  (2025-02-17T12:38:57Z)
• SafeSwitch: Steering Unsafe LLM Behavior via Internal Activation Signals [50.463399903987245]
  Large language models (LLMs) exhibit exceptional capabilities across various tasks but also pose risks by generating harmful content.<n>We show that LLMs can similarly perform internal assessments about safety in their internal states.<n>We propose SafeSwitch, a framework that regulates unsafe outputs by utilizing the prober-based internal state monitor.
  arXiv  Detail & Related papers  (2025-02-03T04:23:33Z)
• Seeker: Towards Exception Safety Code Generation with Intermediate Language Agents Framework [58.36391985790157]
  In real world software development, improper or missing exception handling can severely impact the robustness and reliability of code. We explore the use of large language models (LLMs) to improve exception handling in code. We propose Seeker, a multi-agent framework inspired by expert developer strategies for exception handling.
  arXiv  Detail & Related papers  (2024-12-16T12:35:29Z)
• SJMalloc: the security-conscious, fast, thread-safe and memory-efficient heap allocator [0.0]
  Heap-based exploits pose a significant threat to application security. hardened allocators have not been widely adopted in real-world applications. SJMalloc stores its metadata out-of-band, away from the application's data on the heap. SJMalloc demonstrates a 6% performance improvement compared to GLibcs allocator, while using only 5% more memory.
  arXiv  Detail & Related papers  (2024-10-23T14:47:12Z)
• Towards Exception Safety Code Generation with Intermediate Representation Agents Framework [54.03528377384397]
  Large Language Models (LLMs) often struggle with robust exception handling in generated code, leading to fragile programs that are prone to runtime errors.<n>We propose Seeker, a novel multi-agent framework that enforces exception safety in LLM generated code through an Intermediate Representation (IR) approach.<n>Seeker decomposes exception handling into five specialized agents: Scanner, Detector, Predator, Ranker, and Handler.
  arXiv  Detail & Related papers  (2024-10-09T14:45:45Z)
• Characterizing Unsafe Code Encapsulation In Real-world Rust Systems [2.285834282327349]
  Interior unsafe is an essential design paradigm advocated by the Rust community in system software development. The Rust compiler is incapable of verifying the soundness of a safe function containing unsafe code. We propose a novel unsafety isolation graph to model the essential usage and encapsulation of unsafe code.
  arXiv  Detail & Related papers  (2024-06-12T06:59:51Z)
• Bringing Rust to Safety-Critical Systems in Space [1.0742675209112622]
  Rust aims to drastically reduce the chance of introducing bugs and produces overall more secure and safer code. This work provides a set of recommendations for the development of safety-critical space systems in Rust.
  arXiv  Detail & Related papers  (2024-05-28T12:48:47Z)
• A Mixed-Methods Study on the Implications of Unsafe Rust for Interoperation, Encapsulation, and Tooling [2.2463451968497425]
  Rust developers need verification tools that can provide guarantees of soundness within multi-language applications. We study how developers reason about foreign function calls, the limitations of the tools that they currently use, their motivations for using unsafe code, and how they reason about encapsulating it.
  arXiv  Detail & Related papers  (2024-04-02T18:36:21Z)
• CodeAttack: Revealing Safety Generalization Challenges of Large Language Models via Code Completion [117.178835165855]
  This paper introduces CodeAttack, a framework that transforms natural language inputs into code inputs. Our studies reveal a new and universal safety vulnerability of these models against code input. We find that a larger distribution gap between CodeAttack and natural language leads to weaker safety generalization.
  arXiv  Detail & Related papers  (2024-03-12T17:55:38Z)
• GWP-ASan: Sampling-Based Detection of Memory-Safety Bugs in Production [30.534320345970286]
  heap-use-after-free and heap-buffer-overflow bugs remain the primary problem for security, reliability, and developer productivity for applications written in C or C++. This paper describes a family of tools that detect these two classes of memory-safety bugs, while running in production, at near-zero overhead.
  arXiv  Detail & Related papers  (2023-11-15T21:41:53Z)
• All Languages Matter: On the Multilingual Safety of Large Language Models [96.47607891042523]
  We build the first multilingual safety benchmark for large language models (LLMs) XSafety covers 14 kinds of commonly used safety issues across 10 languages that span several language families. We propose several simple and effective prompting methods to improve the multilingual safety of ChatGPT.
  arXiv  Detail & Related papers  (2023-10-02T05:23:34Z)
• A Static Evaluation of Code Completion by Large Language Models [65.18008807383816]
  Execution-based benchmarks have been proposed to evaluate functional correctness of model-generated code on simple programming problems. static analysis tools such as linters, which can detect errors without running the program, haven't been well explored for evaluating code generation models. We propose a static evaluation framework to quantify static errors in Python code completions, by leveraging Abstract Syntax Trees.
  arXiv  Detail & Related papers  (2023-06-05T19:23:34Z)
• CodeLMSec Benchmark: Systematically Evaluating and Finding Security Vulnerabilities in Black-Box Code Language Models [58.27254444280376]
  Large language models (LLMs) for automatic code generation have achieved breakthroughs in several programming tasks. Training data for these models is usually collected from the Internet (e.g., from open-source repositories) and is likely to contain faults and security vulnerabilities. This unsanitized training data can cause the language models to learn these vulnerabilities and propagate them during the code generation procedure.
  arXiv  Detail & Related papers  (2023-02-08T11:54:07Z)
• SafeText: A Benchmark for Exploring Physical Safety in Language Models [62.810902375154136]
  We study commonsense physical safety across various models designed for text generation and commonsense reasoning tasks. We find that state-of-the-art large language models are susceptible to the generation of unsafe text and have difficulty rejecting unsafe advice.
  arXiv  Detail & Related papers  (2022-10-18T17:59:31Z)
• Natural Language to Code Translation with Execution [82.52142893010563]
  Execution result--minimum Bayes risk decoding for program selection. We show that it improves the few-shot performance of pretrained code models on natural-language-to-code tasks.
  arXiv  Detail & Related papers  (2022-04-25T06:06:08Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.