This paper explores practical strategies for hardening C and C++ software against memory safety vulnerabilities without relying on memory-safe languages or rewriting entire codebases. It focuses on compiler-based mitigations, leveraging techniques like Control-Flow Integrity (CFI) and Shadow Stacks, and highlights how these can be effectively deployed even in complex, legacy projects with limited resources. The paper emphasizes the importance of a layered security approach, combining static and dynamic analysis tools with runtime protections to minimize attack surfaces and contain the impact of potential exploits. It argues that while a complete shift to memory-safe languages is ideal, these mitigation techniques offer valuable interim protection and represent a pragmatic approach for enhancing the security of existing C/C++ software in the real world.
Marco Cantu has finished annotating the "Mastering Delphi 5" book, making it available as a free PDF download. This updated edition provides modern context and corrections to the 20-year-old text, focusing on the core Delphi language and VCL framework concepts that remain relevant today. While acknowledging some outdated aspects, the annotations aim to clarify the book's content for a contemporary audience and highlight its enduring value for learning fundamental Delphi programming principles. Cantu sees this project as a stepping stone towards similarly updating his "Mastering Delphi 7" book.
Hacker News users reacted to the updated "Mastering Delphi 5" with a mix of nostalgia and pragmatism. Several commenters reminisced about Delphi's past prominence and ease of use, fondly recalling their experiences with the platform and its RAD capabilities. Others questioned the relevance of Delphi 5 in the modern development landscape, acknowledging its legacy but expressing concerns about its limitations compared to newer technologies. Some pointed out the niche areas where Delphi still thrives, such as industrial automation and legacy system maintenance, highlighting the value of the updated book for developers in those fields. A few users also discussed the merits of sticking with older, stable technologies versus constantly chasing the latest trends, with some advocating for the simplicity and reliability of mature platforms like Delphi 5.
This GitHub repository preserves incredibly early versions of Dennis Ritchie's Portable C Compiler, including pre-1.0 snapshots dating back to the late 1970s. These versions offer a fascinating glimpse into the evolution of C, showcasing its transition from a research language to the widespread programming powerhouse it became. The repository aims to archive these historically significant artifacts, making them available for study and exploration by those interested in the origins and development of C. It includes various versions for different architectures, providing valuable insights into early compiler design and the challenges of portability in the nascent days of Unix.
Hacker News users discussed the historical significance of the rediscovered C compiler source code, noting its use of PDP-11 assembly and the challenges of porting it to modern systems due to its tight coupling with the original hardware. Several commenters expressed interest in its educational value for understanding early compiler design and the evolution of C. Some debated the compiler's true "firstness," acknowledging earlier, possibly lost, versions, while others focused on the practical difficulties of building and running such old code. A few users shared personal anecdotes about their experiences with early C compilers and PDP-11 machines, adding a personal touch to the historical discussion. The overall sentiment was one of appreciation for the preservation and sharing of this piece of computing history.
Maintaining software long-term is a complex and often thankless job. The original developer's vision can become obscured by years of updates, bug fixes, and evolving user needs. Maintaining compatibility with older systems while incorporating new technologies and features presents a constant balancing act. Users often underestimate the effort involved in seemingly simple changes, and the pressure to deliver quick fixes can lead to technical debt. Documentation becomes crucial but is often neglected, making it harder for new maintainers to onboard. Burnout is a real concern, especially when dealing with limited resources and user entitlement. Ultimately, long-term maintenance is about careful planning, continuous learning, and managing expectations, both for the users and the maintainers themselves.
HN commenters largely agreed with the author's points about the difficulties of long-term software maintenance, citing their own experiences with undocumented, complex, and brittle legacy systems. Several highlighted the importance of good documentation, modular design, and automated testing from the outset to mitigate future maintenance headaches. Some discussed the tension between business pressures that prioritize new features over maintenance and the eventual technical debt this creates. Others pointed out the psychological challenges of maintaining someone else's code, including deciphering unclear logic and fearing unintended consequences of changes. A few suggested the use of static analysis tools and refactoring techniques to improve code understandability and maintainability. The overall sentiment reflected a shared understanding of the often unglamorous but essential work of maintaining existing software and the need for prioritizing sustainable development practices.
No, COBOL does not inherently default to 1875-05-20 for corrupt or missing dates. The appearance of this specific date likely stems from particular implementations or custom error handling within specific COBOL systems. The language itself doesn't prescribe this default. Instead, how COBOL handles invalid dates depends on the compiler, runtime environment, and how the program was written. A program might display a default value, a blank date, or trigger an error message, among other possibilities. The 1875-05-20 date is potentially an arbitrary choice made by a programmer or a consequence of how a specific system interprets corrupted data.
Hacker News users discuss various potential reasons for the 1875-05-20 default date in COBOL, with speculation centering around it being an arbitrary "filler" value chosen by programmers or a remnant of test data. Some commenters suggest it might relate to specific COBOL implementations or be a misinterpretation of a different default behavior, like zeroing out the date field. Others offer alternative explanations, proposing it could represent the earliest representable date in a particular system or stem from a known data corruption issue. A few emphasize the importance of context and specific COBOL versions, noting that the behavior isn't a universal standard. The overall tone suggests the specific date's origin is uncertain and likely varies depending on the system in question.
True seniority as a software engineer isn't just about technical prowess, but also navigating the complexities of existing systems. Working on a legacy project forces you to confront imperfect code, undocumented features, and the constraints of outdated technologies. This experience cultivates essential skills like debugging intricate problems, understanding system-wide implications of changes, making pragmatic decisions amidst technical debt, and collaborating with others who've inherited the system. These challenges, while frustrating, ultimately build a deeper understanding of software development's lifecycle and hone the judgment necessary for making informed, impactful contributions to any project, new or old. This experience is invaluable in shaping a well-rounded and truly senior engineer.
Hacker News users largely disagreed with the premise of the linked article. Several commenters argued that working on legacy code doesn't inherently make someone a senior engineer, pointing out that many junior developers are often assigned to maintain older projects. Instead, they suggested that seniority comes from a broader range of experience, including designing and building new systems, mentoring junior developers, and understanding the business context of their work. Some argued that the article conflated "seniority" with "experience" or "tenure." A few commenters did agree that legacy code experience is valuable, but emphasized it as just one aspect of becoming a senior engineer, not the defining factor. Several highlighted the important skills gained from grappling with legacy systems, such as debugging, refactoring, and understanding complex codebases.
Summary of Comments ( 53 )
https://news.ycombinator.com/item?id=43532220
Hacker News users discussed the practicality and effectiveness of the proposed "TypeArmor" system for securing C/C++ code. Some expressed skepticism about its performance overhead and the complexity of retrofitting it onto existing projects, questioning its viability compared to rewriting in memory-safe languages like Rust. Others were more optimistic, viewing TypeArmor as a potentially valuable tool for hardening legacy codebases where rewriting is not feasible. The discussion touched upon the trade-offs between security and performance, the challenges of integrating such a system into real-world projects, and the overall feasibility of achieving robust memory safety in C/C++ without fundamental language changes. Several commenters also pointed out limitations of TypeArmor, such as its inability to handle certain complex pointer manipulations and the potential for vulnerabilities in the TypeArmor system itself. The general consensus seemed to be cautious interest, acknowledging the potential benefits while remaining pragmatic about the inherent difficulties of securing C/C++.
The Hacker News post titled "How to Secure Existing C and C++ Software Without Memory Safety [pdf]" (https://news.ycombinator.com/item?id=43532220) has several comments discussing the linked pre-print paper and its proposed approach.
Several commenters express skepticism about the practicality and effectiveness of the proposed "Secure by Construction" approach. One commenter argues that while the idea is intriguing, the complexity and effort required to retrofit existing codebases would be prohibitive. They suggest that focusing on memory-safe languages for new projects would be a more efficient use of resources. Another commenter echoes this sentiment, pointing out the difficulty of achieving comprehensive coverage with this technique and the potential for subtle bugs to be introduced during the transformation process.
A thread of discussion emerges around the comparison between this approach and using Rust. Some argue that Rust's inherent memory safety features offer a more robust solution, while others point out that rewriting large C/C++ codebases in Rust is not always feasible. The "Secure by Construction" method is positioned as a potential compromise for situations where a complete rewrite is impossible.
One commenter questions the claim that the technique doesn't require memory safety, suggesting that it essentially introduces a form of dynamic memory safety through runtime checks. They further highlight the potential performance overhead associated with these checks.
Another commenter expresses interest in the potential for automated tools to assist in the process of applying the "Secure by Construction" transformations. They also raise the concern about the potential impact on code readability and maintainability.
Some commenters offer alternative solutions, such as using address sanitizers and static analysis tools to identify and mitigate memory-related vulnerabilities in existing C/C++ code.
A few commenters engage in a more technical discussion about the specifics of the proposed technique, debating the effectiveness of the different transformation rules and the potential for false positives or negatives. They also discuss the challenge of handling complex data structures and pointer arithmetic.
Overall, the comments reflect a cautious interest in the proposed "Secure by Construction" approach, with many expressing reservations about its practicality and effectiveness compared to other solutions like using Rust or focusing on more traditional security hardening techniques. The discussion highlights the ongoing challenge of securing existing C/C++ codebases and the trade-offs involved in different approaches.