Re: SCM_PTR_LE ?

[Marius Vollmer]

Han-Wen <address@hidden> writes:

> address@hidden writes:
> > Han-Wen <address@hidden> writes:
> > 
> > > Can anyone explain to me why for the love of god, we have _macros_ to
> > > compare pointers? (i.e. SCM_PTR_LT, SCM_PTR_GE) ?  SCM sources
> > > indicate that this is to support Turbo C running in protected mode on
> > > i386.
> > > 
> > > I suggest it be scrapped.
> > 
> > Hmm.  The macros look like a potentially useful abstraction to me.  We
> > are not making use of it right now, but it wouldn't feel right to just
> > remove them and thereby destroy information.
> 
> I think that pointer comparison is pretty well defined in ANSI C; can
> you think of a solid reason to support them?

What is that definition?  I think ANSI C only defines the outcome of
comparisons for pointers that point into the same object, i.e., the
same array or a single block returned from malloc.  A consequence
would be that you can not reliably test whether a pointer does point
into some object, since the results are not defined when it points
outside.  For example, is the following guaranteed to print "sane"?

    char block1[100];
    char block2[100];

    char *ptr = block1 + 50;

    if (ptr >= block2 && ptr < block2+100)
      printf ("sane\n");
    else
      printf ("insane\n");

I don't know.    

> Not that this one instance bugs in particular, but the GUILE source
> code is full of these so called "abstractions" that don't solve any
> existing problem, and just make the source code hard to read and
> debug.  I think we can not have too little unnecessary abstractions.

Agreed.  I'm not convinced yet that the PTR_LT abstractions is really
unnecessary.  I can understand the urge to go in and just rewrite the
whole thing so that it be pretty.  The main reason I don't write much
kernel code is the crappy coding style of Linux.  (Not really.)  Also,
it is hard to maintain seemingly useless abstractions while writing
new code.  We can probably get away without using SCM_PTR_LT properly
in the future, but maybe it will come back and bite us.  You have just
introduced the SCM_WRITABLE_VELTS abstraction which is at present also
unnecessary, but it might become critical in the future.

Anyway, pending the ANSI C issue above, I'm actually sympathetic to
removing of SCM_PTR_LT.  It really feels a bit silly.