November 24, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | On Tuesday, 24 November 2020 at 00:08:57 UTC, Ola Fosheim Grostad wrote:
> On Monday, 23 November 2020 at 20:00:29 UTC, Patrick Schluter wrote:
>> On Monday, 23 November 2020 at 12:39:05 UTC, Ola Fosheim Grøstad wrote:
>>> A trap is an interrupt at the hardware level. It has nothing to do with C.
>>
>> Read the C standard, they explain what a trap representation is. It has nothing to do with an interrupt. I refer to the C standard because they make the difference between allowed pointer values and unallowed values even if never dereferenced.
>
> When I intoduced the word "trap" in this discussion I used the traditional hardware terminology as used in Motorola 68K reference manuals. Has nothing to do with C whatsoever.
I introduced the expression "trap representation" from the C standard (and I specified explicitly the context I said "null is not a trap representation as a C standard would call it.").
Understanding this as meaning the 68000 trap# instruction can only be done either in bad faith, either from stupidity*. Choose your case.
Bye, no further involvement from my part.
* I know it's a false dichotomy, there's a third possibility but it is not positive for you either (you misunderstood and are too proud to admit it).
|
November 24, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Tuesday, 24 November 2020 at 08:47:03 UTC, Patrick Schluter wrote:
> Understanding this as meaning the 68000 trap# instruction can only be done either in bad faith, either from stupidity*.
I don't know what you are problem is here.
Motorola terminology: trap
Intel terminology: exception
Both mean interrupt.
I chose to use the term "trap" to avoid confusion.
|
November 24, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Tuesday, 24 November 2020 at 08:47:03 UTC, Patrick Schluter wrote:
> I introduced the expression "trap representation" from the C standard (and I specified explicitly the context I said "null is not a trap representation as a C standard would call it.").
> Understanding this as meaning the 68000 trap# instruction can only be done either in bad faith, either from stupidity*. Choose your case.
Another note, please stop assuming what people are trying to cause harm to you. It is not productive.
In case there is any doubt: I wrote "trap" with then intent of referring to a hardware exception. You seemed to read that in a more general sense and brought in the C standard, which is not relevant. So I can only assume that my intent was not conveyed as clearly as I wanted therefore I tried to make it clear. I apologize if you take offense by my attempt to make my intent clear.
The C standard terminology is actually of no relevance when discussing the wording of the D spec: The pointee (object) is not valid for a null pointer, so it is indeed invalid (the pointee is).
|
Copyright © 1999-2021 by the D Language Foundation