C# includes an unsafe keyword that enables pointer types and pointer operators for scenarios like operating system interop, memory-mapped devices, and time-critical code. Unsafe code is currently treated as having no effect on type or member safety enforcement beyond allowing pointer usage. A new memory-safety model is planned for C# 16, with previews in C# 15 and .NET 11, and a .NET 12 LTS release later. Marking a method as unsafe will also mark it as requires-unsafe, forcing callers to be in an unsafe context. Overrides will be restricted so safe base members cannot be overridden with unsafe implementations. Propagation can be suppressed by including an unsafe context within a method without marking that method as unsafe.
"In the new model, marking a method as unsafe will "also mark it as requires-unsafe, meaning callers must be in an unsafe context and overrides cannot be unsafe if the base members is safe," states the current language proposal. This means that the unsafe designation propagates to callers until it is suppressed by including an unsafe context within a method, but not marking the method as unsafe."
"Many C# developers never use unsafe, but it has been part of the language from its first release. "Writing unsafe code is like writing C code within a C# program," said an early book called The C# Programming Language, written by its inventor Anders Hejlsberg and others. Examples of where unsafe code is necessary include interop with the underlying operating system, accessing memory-mapped devices, or implementing time-critical code."
"Unsafe code allows the use of pointer types, which are not tracked by the .NET garbage collector, and pointer operators. Other than that, the existing unsafe modifier has no effect on a type or member."
"We envision a future where C# is among a set of languages chosen and noted for the type- and memory-safety enforcement," said Lander."
Read at theregister
Unable to calculate read time
Collection
[
|
...
]