Stories with Tag C interop

• Fortran for C Programmers

  permalink

  Posted: 2025-05-17 23:41:54

  Verbose tl;dr

  This document provides a concise guide for C programmers transitioning to Fortran. It highlights key differences, focusing on Fortran's array handling (multidimensional arrays and array slicing), subroutines and functions (pass-by-reference semantics and intent attributes), derived types (similar to structs), and modules (for encapsulation and namespace management). The guide emphasizes Fortran's column-major array ordering, contrasting it with C's row-major order. It also explains Fortran's powerful array operations and intrinsic functions, allowing for optimized numerical computation. Finally, it touches on common Fortran features like implicit variable declarations, formatting with FORMAT statements, and the use of ALLOCATE and DEALLOCATE for dynamic memory management.

  This document, titled "Fortran for C Programmers," serves as a comprehensive guide for experienced C programmers transitioning to Fortran. It meticulously outlines the key differences and similarities between the two languages, enabling a smoother learning curve. The guide begins by highlighting Fortran's strengths, particularly in numerical computation and scientific computing, emphasizing its array handling capabilities and optimized performance for complex mathematical operations.

  The document then delves into the specifics of Fortran syntax and semantics, comparing and contrasting them with their C counterparts. It covers fundamental concepts like data types, variable declarations, and operators, meticulously explaining how these elements differ between the languages. For instance, it discusses the implicit typing conventions in Fortran, where variable names starting with certain letters default to specific data types, unlike C's explicit declarations. It also explores the concept of kind parameters in Fortran, which allow for precise control over the size and precision of numeric types, offering a level of granularity not readily available in standard C.

  The guide further elucidates the distinctions in array handling, a cornerstone of Fortran's prowess in scientific computing. It explains Fortran's multidimensional arrays and their column-major order storage, contrasting this with C's row-major order. The document details how array operations and slicing work in Fortran, emphasizing the language's built-in support for vectorized operations, which often leads to significant performance gains compared to equivalent C code using explicit loops.

  Control flow structures, including conditional statements (if, else if, else) and loops (do, while), are also meticulously compared. While the basic structure remains largely similar, the guide highlights syntactic variations and specific features like Fortran's "cycle" and "exit" statements for loop control.

  Furthermore, the document addresses the topic of functions and subroutines in Fortran, their parameter passing mechanisms (by reference being the default), and how they relate to C's function calls. It clarifies the distinction between subroutines, which do not return values, and functions, which do. The document also explains how to interface Fortran code with C libraries, enabling programmers to leverage existing C code within Fortran projects.

  The guide also touches upon advanced Fortran features such as modules, which facilitate code organization and encapsulation similar to C++ classes, and derived types, allowing users to create custom data structures. It explores the concept of operator overloading in Fortran, enabling customized behavior for operators used with derived types.

  Finally, the document underscores the importance of compilers and build systems in Fortran development. It briefly discusses the role of compilers in optimizing Fortran code for high-performance computing and provides guidance on compiling and linking Fortran programs. This comprehensive comparison provides a strong foundation for C programmers to understand and effectively utilize the power of Fortran for scientific and numerical computing tasks.

  • Fortran
  • C
  • Programming Languages
  • Interoperability
  • Comparison
  • Tutorial
  • Flang
  • LLVM
  • compiler
  • Code Translation
  • C interop
  • Fortran Programming
  • C Programming

  Summary of Comments ( 3 )
  https://news.ycombinator.com/item?id=44017832

  Verbose tl;dr

  Hacker News users discuss Fortran's continued relevance, particularly in scientific computing, highlighting its performance advantages and ease of use for numerical tasks. Some commenters share personal anecdotes of Fortran's simplicity for array manipulation and its historical dominance. Concerns about ecosystem tooling and developer mindshare are also raised, questioning whether Fortran offers advantages over modern C++ for new projects. The discussion also touches on specific language features like derived types and allocatable arrays, comparing their implementation in Fortran to C++. Several users express interest in learning modern Fortran, spurred by the linked resource.

  The Hacker News post "Fortran for C Programmers" (linking to Fortran documentation aimed at C programmers) generated a moderate discussion with several interesting comments. Many focused on the persistent relevance and niche strengths of Fortran, particularly in scientific computing.

  Several commenters highlighted Fortran's continued dominance in high-performance computing (HPC) and specific scientific domains. They pointed out that despite its age, Fortran's design is well-suited for numerical computation and its compilers are highly optimized for performance on specialized hardware like vector processors. This makes it a difficult language to displace in fields like weather forecasting, climate modeling, and computational fluid dynamics, where raw performance is critical.

  One commenter even described Fortran as "the COBOL of scientific computing," alluding to its entrenched position and the significant amount of legacy code that continues to function reliably. While this might seem like a criticism, the context suggested an acknowledgement of Fortran's enduring practicality in its domain.

  Another thread of discussion revolved around the relative strengths and weaknesses of Fortran compared to C. Commenters discussed the specific advantages Fortran offers for numerical computation, such as its built-in array operations and support for complex numbers. Some users also appreciated Fortran's more straightforward syntax for certain mathematical operations. Conversely, they acknowledged C's greater flexibility for general-purpose programming and its wider ecosystem of libraries and tools.

  A few commenters shared personal anecdotes about using Fortran in their own scientific work or education. These stories provided real-world context to the discussion, illustrating the language's continued use in both academic and industrial settings.

  The overall sentiment towards Fortran was surprisingly positive, with many commenters acknowledging its continued importance despite the popularity of newer languages. The discussion painted a picture of Fortran as a specialized tool that remains highly effective for its intended purpose, even if its overall popularity has declined. While the number of comments isn't overwhelming, they provide a good overview of the reasons for Fortran's continued existence in the scientific computing world.

• Show HN: I built a Rust crate for running unsafe code safely

  permalink

  Posted: 2025-04-06 13:28:48

  Verbose tl;dr

  mem-isolate is a Rust crate designed to execute potentially unsafe code within isolated memory compartments. It leverages Linux's memfd_create system call to create anonymous memory mappings, allowing developers to run untrusted code within these confined regions, limiting the potential damage from vulnerabilities or exploits. This sandboxing approach helps mitigate security risks by restricting access to the main process's memory, effectively preventing malicious code from affecting the wider system. The crate offers a simple API for setting up and managing these isolated execution environments, providing a more secure way to interact with external or potentially compromised code.

  The Hacker News post titled "Show HN: I built a Rust crate for running unsafe code safely" introduces mem-isolate, a new Rust library designed to mitigate the risks associated with executing potentially unsafe code. The core concept behind mem-isolate is compartmentalization. It achieves this by leveraging Rust's ownership system and memory safety guarantees to create isolated memory regions, effectively sandboxing the execution of untrusted or volatile code.

  This sandboxing prevents potential memory corruption or other undefined behavior from affecting the primary application. If the isolated code attempts an illegal memory access or performs another unsafe operation that would typically lead to a crash or vulnerability, the effects are confined within the isolated memory region. The main application remains unaffected, enhancing overall system stability and security.

  The crate provides a mechanism to execute a given function within this confined environment. It works by forking the current process and establishing the isolated memory space within the child process. The target function then runs solely within this isolated child process. Any memory violations or crashes are isolated to the child process, preventing them from propagating to the parent and compromising the main application. The parent process can then continue operating normally.

  The developer highlights that while mem-isolate focuses on memory safety, it doesn't address all potential security concerns. For example, it doesn't inherently protect against issues like infinite loops or excessive resource consumption within the isolated code. These aspects would require additional monitoring and control mechanisms.

  Essentially, mem-isolate offers a way to run potentially dangerous code within a controlled environment, significantly reducing the risks associated with executing untrusted code within a Rust application, particularly focusing on preventing memory-related vulnerabilities from impacting the core application's integrity.

  • Rust
  • crate
  • unsafe
  • safe
  • Memory Safety
  • Sandboxing
  • isolation
  • System Programming
  • Low-level
  • FFI
  • Foreign Function Interface
  • C interop
  • WebAssembly
  • Wasm
  • Security
  • Operating Systems
  • Kernel
  • mem-isolate

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=43601301

  Verbose tl;dr

  Hacker News users discussed the practicality and security implications of the mem-isolate crate. Several commenters expressed skepticism about its ability to truly isolate unsafe code, particularly in complex scenarios involving system calls and shared resources. Concerns were raised about the performance overhead and the potential for subtle bugs in the isolation mechanism itself. The discussion also touched on the challenges of securely managing memory in Rust and the trade-offs between safety and performance. Some users suggested alternative approaches, such as using WebAssembly or language-level sandboxing. Overall, the comments reflected a cautious optimism about the project but acknowledged the difficulty of achieving complete isolation in a practical and efficient manner.

  The Hacker News post "Show HN: I built a Rust crate for running unsafe code safely" (linking to the mem-isolate crate) generated a moderate amount of discussion, mostly focused on the complexities and nuances of memory safety in Rust, and whether the crate truly offers a "safe" solution for running unsafe code.

  Several commenters express skepticism about the claim of "safely" running unsafe code. One points out the inherent contradiction, suggesting the term is an oxymoron. Another argues that true safety requires formal verification, and anything short of that is merely reducing the attack surface rather than eliminating it. This sentiment is echoed by another commenter who highlights the difficulty in proving the soundness of the approach and the potential for subtle bugs to undermine the isolation.

  A few comments delve into the specifics of mem-isolate's implementation. One user questions its practicality for real-world scenarios, suggesting that the overhead of serialization and deserialization, coupled with the limitations on system call access, could severely limit its usefulness. They also mention the potential performance impact and the challenge of managing data dependencies between isolated processes.

  The discussion also touches upon alternative approaches to isolating unsafe code, such as WebAssembly. One commenter mentions Wasmtime as a more mature and robust solution, although they acknowledge that Wasmtime might not be suitable for all use cases. Another suggests using language-level sandboxing features provided by some languages.

  Some users discuss the trade-offs between security and performance. One commenter notes that while complete memory safety is desirable, it often comes at a cost to performance. They suggest that in certain situations, a calculated risk with less strict isolation might be acceptable if performance is a critical factor.

  Finally, a few comments express general interest in the project and commend the author for tackling a challenging problem. They acknowledge the difficulty of achieving true memory safety in systems programming and appreciate the effort to improve the security of Rust code. However, even these positive comments maintain a cautious tone, reflecting the overall skepticism towards the claim of absolute safety.