Defining the Rust 2024 edition
Defining the Rust 2024 edition
Posted Jan 31, 2024 13:22 UTC (Wed) by bluca (subscriber, #118303)In reply to: Defining the Rust 2024 edition by pbonzini
Parent article: Defining the Rust 2024 edition
Posted Jan 31, 2024 14:25 UTC (Wed)
by mb (subscriber, #50428)
[Link] (6 responses)
Posted Jan 31, 2024 15:46 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (5 responses)
Posted Jan 31, 2024 16:01 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
Posted Jan 31, 2024 19:01 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (3 responses)
Posted Feb 1, 2024 8:38 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Feb 1, 2024 10:07 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Not just C++; even C has this problem to a small degree. The ELF ABIs don't cover the full C language; if I change a significant preprocessor definition, or a const that my library never takes the address of, the resulting .so will not change, and yet I can change my ABI by doing so.
We just ignore this for C, since distros do the work of making sure that C developers don't destabilize their own ABIs this way, but it's still an issue, even in C.
Posted Feb 1, 2024 14:33 UTC (Thu)
by bluca (subscriber, #118303)
[Link]
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition