Range of enum type values

Timon Gehr timon.gehr at gmx.ch
Sat Dec 28 13:33:25 UTC 2019


On 27.12.19 19:12, Johan Engelen wrote:
> 
> [*]
> Let's not go off on a tangent,

It's not a tangent, it's a powerful tool to decide whether something has 
any business being UB or not.

> but there is enough UB in D that I do not accept that @safe=="no UB" argument.

https://dlang.org/articles/safed.html

"In D, we expect the vast majority of programmers to operate within the 
safe subset of D, which we call SafeD. The safety and the ease of use of 
SafeD is comparable to Java—in fact Java programs can be 
machine-translated into this safe subset of D. SafeD is easy to learn 
and it keeps the programmers away from undefined behaviors. It is also 
very efficient."

"[...] you are guaranteed not to encounter any undefined behavior."

https://dlang.org/spec/memory-safe-d.html

"Therefore, the safe subset of D consists only of programming language 
features that are guaranteed to never result in memory corruption. See 
this article for a rationale."

("this article" links to
https://dlang.org/articles/safed.html)

> One example that comes to mind is 
> bitshifting by more than the operand bit width: "illegal" is what the 
> spec says but that doesn't make sense for runtime shift values and, in 
> practice, turns into UB at runtime. ;-)

What that means is not that UB is allowed in @safe code, but rather that 
the spec hasn't been properly updated after @safe was introduced to 
clarify what "illegal" means here. It should mean that the returned 
value is arbitrary, not that the behavior of the entire program will be 
arbitrary. I think Walter has said as much before, but I can't find the 
post.

@safe is meant to imply no memory corruption. @safe implies no UB, 
because UB can lead to any behavior, including memory corruption. UB 
allows compilers to insert arbitrary code execution exploits. How can 
you call that @safe?


More information about the Digitalmars-d mailing list