Message from discussion
Questions about pointer comparisons
Path: g2news1.google.com!news3.google.com!feeder.news-service.com!188.40.43.213.MISMATCH!feeder.eternal-september.org!eternal-september.org!not-for-mail
From: Kaz Kylheku <kkylh...@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Questions about pointer comparisons
Date: Wed, 2 Dec 2009 00:48:18 +0000 (UTC)
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <20091201164546.977@gmail.com>
References: <39474e22-259a-448f-9ba4-f3d1a8de099d@m3g2000yqf.googlegroups.com>
<7nkgshF3lna8iU1@mid.uni-berlin.de>
<6e65bd75-6614-4f34-8b3c-71ab75fa3366@m25g2000yqc.googlegroups.com>
<f69b1eaf-6416-49fd-ab01-d34ca8b7b2b3@c34g2000yqn.googlegroups.com>
<57f5ca82-62e1-4969-bcc9-25e57de79679@d10g2000yqh.googlegroups.com>
<slrnhhb4l9.570.usenet-nospam@guild.seebs.net>
<2629d76a-226e-4b57-abcc-06de8a9b6650@m16g2000yqc.googlegroups.com>
<slrnhhbd3k.oi0.usenet-nospam@guild.seebs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news.eternal-september.org U2FsdGVkX192zsSb9swV/nHexSf0OWbtltciB1Gopd1O0G3d9DoX9nATsCgi25f82k7NZB/aC6lQ/9ui99dnbbgjPAELpxNvX0/Rsf4Vw+AGGV2yt4MfD/aP/cUOFtMeqQ6zS9CY03wlCJuu29wmqQ==
X-Complaints-To: abuse@eternal-september.org
NNTP-Posting-Date: Wed, 2 Dec 2009 00:48:18 +0000 (UTC)
X-Auth-Sender: U2FsdGVkX1+NK4fw4fN9HZOxh8hPHQW9QEhjzwuqiM4rlO0ITv6NVg==
Cancel-Lock: sha1:5LGL62NvFjjiJR/w7sQGvxhnKlE=
User-Agent: slrn/0.9.9p1 (Linux)
On 2009-12-02, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-12-02, Peter Nilsson <ai...@acay.com.au> wrote:
>>> Making !=/== do extra work that's needed to keep things from
>>> blowing up has lower impact than making all the pointer
>>> relational operators do that.
>
>> What extra work? I don't know of a system where 'robust'
>> testing for equality requires anything other than a compare
>> or conditional-branch instruction, neither of which trap.
>> [Happy to be educated though.]
>
> Segmented architectures with pointers that don't include segment information
> by default.
Plural?
Oh, you must be counting 8088, 8086, 80186, etc, as separate architectures.