December 28, 2019 Re: OFF TOPIC Re: Range of enum type values | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | On 12/28/2019 12:22 PM, Johan Engelen wrote: > You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that. > > I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it. > > I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe. What it does mean is that all instances of #safe resulting in #undefinedBehavior should be logged either in bugzilla or noted as an exception in the #specification. Note that there's a bugzilla keyword 'safe' which can tag them. Here's the current set of open tagged issues: https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced |
December 28, 2019 Re: OFF TOPIC Re: Range of enum type values | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | On 28.12.19 21:22, Johan Engelen wrote: > On Saturday, 28 December 2019 at 13:33:25 UTC, Timon Gehr wrote: >> >> @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? > > I think we are talking about different things here. > > You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that. > > I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it. Each of those instances is a bug. > > I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe. I acknowledge that the implementation has bugs. I reported a number of frontend bugs in the type checker myself. What you are saying is that the backends have bugs as well. It's not very surprising, but I don't think you can use existing bugs in the implementation as a justification to deliberately introduce more of those bugs, which is what I read when you write "I don't buy this argument". |
December 28, 2019 Re: OFF TOPIC Re: Range of enum type values | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 28.12.19 22:08, Walter Bright wrote: > On 12/28/2019 12:22 PM, Johan Engelen wrote: >> You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that. >> >> I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it. >> >> I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe. > > What it does mean is that all instances of #safe resulting in #undefinedBehavior should be logged either in bugzilla Yes. > or noted as an exception in the #specification. > ... Yes, but the only reasonable kinds of exceptions are invalid @trusted/@system code or specific compiler flags to disable safety (e.g. -boundscheck=off). There can't be any other exceptions. |
Copyright © 1999-2021 by the D Language Foundation