今日已更新 133 条资讯 | 累计 37382 条内容
关于我们

标签:#vs

找到 215 篇相关文章

AI 资讯

The Rust vs. JavaScript Undefined Behavior Crisis: Lessons from Recent Security Incidents and Cross-Language Compilation Bugs

Originally published on tamiz.pro . The Silent Crisis: Undefined Behavior Across Language Boundaries Recent high-profile security incidents have exposed a growing concern in the software engineering world: undefined behavior (UB) is not just a C/C++ problem anymore. From Rust compilation bugs to JavaScript engine vulnerabilities, developers are witnessing how subtle language design choices can lead to catastrophic failures when code crosses language boundaries or interacts with low-level systems. These incidents aren't isolated — they represent a systemic issue affecting modern software stacks built on heterogeneous language ecosystems. Case Study: The Rust Memory Safety Myth Rust was built with the promise of memory safety without garbage collection. Yet, recent CVEs have revealed that undefined behavior in unsafe Rust blocks can compromise entire systems: The 2024 OpenSSL Rust Port Incident A critical vulnerability was discovered in a Rust port of OpenSSL where unsafe code blocks performed unchecked pointer arithmetic. While the safe Rust layer enforced bounds checking, the unsafe boundary passed raw pointers to the C layer without validation. // Vulnerable pattern discovered in the incident unsafe { let ptr = slice .as_mut_ptr (); // No bounds check - undefined if offset exceeds slice length let unsafe_slice = std :: slice :: from_raw_parts_mut ( ptr , len + offset ); } This wasn't caught by Rust's compiler because it explicitly allows unsafe operations. The UB only manifested during cross-language calls to the underlying C library. The WebAssembly Compilation Bug Another incident involved a Rust-to-Wasm compilation bug where the compiler optimized away what should have been defensive checks, assuming the guarantees of safe Rust would hold at runtime. When these assumptions broke at the Wasm boundary, attackers could trigger heap overflows. JavaScript's Hidden Undefined Behavior While JavaScript is often criticized for loose typing, its recent security incidents

2026-08-21 原文 →
AI 资讯

1a vez trabalhando com git com time: tudo que você precisa saber

Faz mais de 5 anos que eu não abria um PR ou issue técnica no Github, mas essa semana tenho aprendido algumas boas práticas e termos que reuni neste artigo. Introdução Essa semana eu fiz uma coisa simples: atualizei o README de um projeto open source, o 4noobs , da comunidade He4rt. Troquei um badge, ajustei o contraste de um logo, organizei umas pastas e adicionei um índice pra facilitar a navegação. Nada muito complexo no fim das contas. Só que antes de chegar no "nada muito complexo", eu passei um tempo enrolada com uma pergunta boba: "E se eu mandar isso direto pra branch principal e bagunçar tudo?" Se tu já sentiu esse friozinho na barriga antes de mexer num repositório que não é só teu, esse artigo é pra ti. Não importa se tu é dev há anos ou se nunca abriu um terminal na vida... A lógica por trás de "como contribuir sem quebrar nada" é a mesma e bem mais simples do que parece. Definição de Git Colaborativo Quando eu aprendi git há uns anos, aprendi somente o versionamento e a enviar os arquivos pra dentro do Github, mas ele é bem mais que isso, né? É através dele que times enormes interagem a respeito de um mesmo projeto de forma organizada, comentando, gerenciando tarefas, sugerindo melhorias e conhecendo o que os outros envolvidos estão fazendo. Isso é a parte do Git Colaborativo . O Git resolve isso com um conceito central: branches (ou "ramificações"). Cada branch é tipo uma cópia paralela do projeto, onde tu pode mexer à vontade sem afetar a versão "oficial" (geralmente chamada de main ou master ). Quando tu termina sua parte, tu propõe que essas mudanças sejam incorporadas de volta pelo Pull Request (PR) . Ou seja, o fluxo básico é: Tu cria uma branch nova a partir do projeto principal Faz as alterações lá, no seu espaço isolado Envia ( push ) essa branch pro repositório remoto Abre um Pull Request pedindo pra essas mudanças serem revisadas e, se aprovadas, unidas ( merge ) à branch principal Ninguém mexe direto na versão "de produção" do projeto. Isso

2026-08-20 原文 →
AI 资讯

I Got Tired of AI Agents Breaking My System Contracts, So I Built Something to Stop It

Okay, story time. If you've worked on a full stack app where the backend is Java/Spring Boot and the frontend is React, you know the drill. Someone changes something on one side of a contract and nobody tells the other side. Weeks later you're playing detective across five files trying to figure out who calls what. And it's not just REST endpoints. It's the scheduled job that quietly writes to the same table your API touches. It's the service that calls another service, which calls another service. It's the Kafka event your controller publishes that some completely unrelated listener is consuming three modules away. All of that is "the contract" too, it's just invisible unless you go looking for it. Now add AI coding agents into that picture. They're great at writing code in the file they're looking at. They're not great at knowing that the component they're editing calls an endpoint, which hits a controller, which calls a service, which calls a repository, which is also written to by a scheduled job at 2am, which also fires an event three other services are listening for. Agents see one file at a time. So they'll happily rename a field or change a return shape on one side and leave everything downstream of it completely unaware anything changed. I got burned by this enough times that I decided to build the map myself. That's how Contour happened, and then, once I realized AI agents needed to query that map directly instead of just reading it off my screen, Contour MCP happened right after. Let's get into it. The actual problem Working across a UI, a REST API, a service layer, a repository layer, a database, plus schedulers and events sitting on top of all of it, two things go wrong constantly. Agents (and honestly, humans too) edit one side of a flow without knowing the other side exists. People burn real time reconstructing a call chain by hand, jumping through five or six files just to make a change that should be simple. Both come from the same root cause. Nobod

2026-08-07 原文 →