Program logic bugs vs input/environmental errors
Iain Buclaw via Digitalmars-d
digitalmars-d at puremagic.com
Thu Oct 9 09:43:10 PDT 2014
On 9 October 2014 17:33, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Thu, 09 Oct 2014 13:10:34 +0000
> schrieb "Dicebot" <public at dicebot.lv>:
>
>> On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
>> >> Can we at least agree that Dicebot's request for having the
>> >> behaviour of
>> >> inadvisable constructs defined such that an implementation
>> >> cannot randomly
>> >> change behaviour and then have the developers close down the
>> >> corresponding
>> >> bugzilla issue because it was the user's fault anyway is not
>> >> unreasonable by
>> >> definition because the system will not reach a perfect state
>> >> anyway, and then
>> >> retire this discussion?
>> >
>> > I've been working with Dicebot behind the scenes to help
>> > resolve the particular issues with the code he's responsible
>> > for.
>> >
>> > As for D, D cannot offer any guarantees about behavior after a
>> > program crash. Nor can any other language.
>>
>> Just wanted to point out that resulting solution (== manually
>> switching many of contracts to exceptions from asserts) to me is
>> an unhappy workaround to deal with overly opinionated language
>> and not actually a solution. I still consider this a problem.
>
> A point which hasn't been discussed yet:
>
> Errors and therefore assert can be used in nothrow functions. This is a
> pita for compilers because it now can't do certain optimizations. When
> porting GDC to ARM we started to see problems because of that (can't
> unwind from nothrow functions on ARM, program just aborts). And now we
> therefore have to worsen the codegen for nothrow functions because of
> this.
>
> I think Walter sometimes suggested that it would be valid for a
> compiler to not unwind Errors at all (in release mode), but simply kill
> the program and dump a error message. This would finally allow us to
> optimize nothrow functions.
>
This behaviour was agreed at the bar at DConf. We'd have to put it in
the spec to give it the official stamp of approval though.
Iain.
More information about the Digitalmars-d
mailing list