November 24, 2020
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
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
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).

1 2 3 4
Next ›   Last »