Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.forth,comp.lang.c
Subject: Re: LLVM and Forth
Date: Mon, 10 Apr 2017 16:18:18 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <87h91ws345.fsf@bsb.me.uk>
References: <21153661-abf5-4958-82c7-e3c442b45cb9@googlegroups.com> <ZqGdnRes4qCBI33FnZ2dnUU7-VednZ2d@supernews.com> <065e774c-c5fb-4e68-9489-00b5357142d6@googlegroups.com> <qOKdneQNfs-vmH_FnZ2dnUU7-UednZ2d@supernews.com> <2017Apr3.145550@mips.complang.tuwien.ac.at> <NNSdnXwvutwb-H_FnZ2dnUU7-XXNnZ2d@supernews.com> <2017Apr3.190545@mips.complang.tuwien.ac.at> <a-SdnVgDEexEVH7FnZ2dnUU7-RHNnZ2d@supernews.com> <2017Apr5.170145@mips.complang.tuwien.ac.at> <s4wFA.637264$3a3.286206@fx43.am4> <2017Apr9.165301@mips.complang.tuwien.ac.at> <xuAGA.661090$nT1.467590@fx44.am4> <ocerfl$5j4$1@dont-email.me> <HsLGA.931050$vF2.237690@fx46.am4>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="1d08c9970de17e8c0f737000b0a1c08d"; logging-data="22473"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19zvcpboEc6JEHCDyXaAAZqUPnqZtA8l+o="
Cancel-Lock: sha1:WI2Iv30RrPh0+5SsOYP3iizq/hY= sha1:WeJMacjco1N6XB1y0NhKQa5olVQ=
X-BSB-Auth: 1.30c4681b4177cd23cbec.20170410161818BST.87h91ws345.fsf@bsb.me.uk
Xref: csiph.com comp.lang.forth:57003 comp.lang.c:107996

Spiros Bousbouras <spibou@gmail.com> writes:

> On Sun, 9 Apr 2017 22:46:04 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 04/09/2017 08:38 PM, Spiros Bousbouras wrote:
>> > [ Crossposted to  comp.lang.c  since we need some C lawyers ;-) ]
>> > 
>> > On Sun, 09 Apr 2017 14:53:01 GMT
>> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
> [...]
>
>> > Before you go to the C standards committee you need to have a specific proposal. I
>> > take it that for C to be a suitable back end for implementing Forth , you want
>> > comparison of C pointers pointing to different objects to be defined. Could you
>> 
>> Note: C++ requires that std::less<T*> must provide a total ordering of
>> all pointers of type T*, even if the "<" operator does not provide such
>> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
>> with C that the fact that the C++ standard can successfully impose this
>> requirement strongly suggests that the C standard could impose a similar
>> requirement.
>> However, it's telling that C++ did NOT impose this requirement on the
>> "<" operator itself, but only on std::less<T*>. That's because there are
>> some systems where meeting this requirement makes std::less<T*>(p,q)
>> substantially slower than p<q.
>
> I wonder if for Anton's purposes and for a big endian machine the following
> would do
>
> int compare_pointers_to_void(void **p1 , void **p2) {
>     return memcmp(*p1 , *p2 , sizeof(void *)) ;
> }

That seems unlikely.  You might have meant

  int compare_pointers_to_void(void **p1, void **p2) {
      return memcmp(p1, p2, sizeof (void *));
  }

or, possibly,

  int compare_pointers_to_void(void *p1, void *p2) {
      return memcmp(&p1, &p2, sizeof (void *));
  }

Note that using the idiom:

  memcmp(<exp1>, <exp2>, sizeof *<exp1>);

can highlight indirection issues like this.  Your example written in
this style is

  int compare_pointers_to_void(void **p1, void **p2) {
      return memcmp(*p1, *p2, sizeof **p1);
  }

and sizeof **p1 is sizeof a void object -- undefined.

But even fixed, I doubt that comparing the representation of the
pointers is a good idea.  If the system uses some peculiar segmented
architecture, that's going to go wrong.  Even though it's not portable,
the best solution is usually to convert to an integer type.  Where that
is meaningful, C99 implementations provide the type uintptr_t in
stdint.h.

<snip>
-- 
Ben.