Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: "Rod Pemberton" <dont_use_email@xnohavenotit.cnm>
Newsgroups: comp.lang.forth
Subject: Re: CASE mis-understanding?
Date: Fri, 28 Feb 2014 16:20:18 -0500
Organization: Aioe.org NNTP Server
Lines: 72
Message-ID: <op.xb0f742c5zc71u@localhost>
References: <52e54d17.461102185@news.demon.co.uk> <7xlhwwela4.fsf@ruckus.brouhaha.com> <530f5e60$0$25041$e4fe514c@dreader37.news.xs4all.nl> <op.xbylp0b95zc71u@localhost> <53107156$0$25040$e4fe514c@dreader37.news.xs4all.nl>
NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Opera Mail/12.16 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.forth:28835

On Fri, 28 Feb 2014 06:21:58 -0500, Albert van der Horst  
<albert@spenarnc.xs4all.nl> wrote:
> In article <op.xbylp0b95zc71u@localhost>,
> Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
>> On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst
>> <albert@spenarnc.xs4all.nl> wrote:
>>> In article <7xlhwwela4.fsf@ruckus.brouhaha.com>,
>>> Paul Rubin  <no.email@nospam.invalid> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>>>>> How is that semantically different from a null pointer?  Surely NIL
>>>>> is a null pointer, however it is represented.
>>>>
>>>> Each list node is a discriminated union (member of a sum type) that's
>>>> either NIL, or a pair consisting of a value and a pointer to the next
>>>> node.  So in the case where it's NIL, that's not a pointer.  With a
>>>> static type system, if the list has a type like List<A>, the NIL for
>>>> that list would also have that type, and any attempt to dereference it
>>>> would be caught at compile time.
>>>
>>> So instead of a runtime system that gives an error:
>>> "attempt to derefence a nil pointer" the user is obliged to put
>>> some code in to give that error himself. Big advantage -;)
>>>
>>> Really, on paper and properly implemented, the null pointer in C is
>>> a fairly decent nil value. Properly implemented in my book means
>>> that an access through the pointer must be trapped.
>>>
>>
>> AFAIK, there's no requirement in C to prevent reading or writing to the
>> same address as the NULL pointer.  AFAIK, there is no requirement to
>> trap accesses to it's location either.  The requirement is that no C  
>> objects
>> must be located *at* the NULL pointer address.  The NULL is for  
>> comparing
>> a pointer in C against NULL to determine if the pointer was set or not.
>> [...]
>
> You have not said that you disagree with me and consider that a
> proper, high quality implementation.
>

Why do you think that a high quality implementation of C needs
to trap accesses through a NULL pointer?

There are two things that trapping NULL accesses does:
1) prevent accidental usage of an uninitialized pointer
2) prohibit access to a region of memory

#1 is generally regarded as a good thing.  But, #2 is a serious problem.
Most architectures need to access the area of memory where the NULL
pointer points (i.e., commonly address zero).

So, are you saying the advantages of #1 outweighs the necessity of #2?

If the NULL pointer was set to a region where no memory exists or where
the operating system prohibits access, then trapping NULL accesses wouldn't
interfere with #2.  In that case, it would be acceptable to trap.  But,
most versions of C aren't setup that way.

Due to the way most versions of C are setup, I'd have to say it's generally
undesirable to trap, but when properly implemented it would be beneficial.

To trap accesses without large amounts of additional code, you'd need to
be on an architecture which supports hardware paging of memory.  I.e., it'd
work on modern x86, but probably not on older mainframes or 8-bit micro's.
So, you really need to specify the capabilities of the hardware as a
constraint as to where a high quality implementation of C could be  
available.


Rod Pemberton