SCM_PTR_LE ?

SCM_PTR_LE ?

[Han-Wen]

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.




-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> 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.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Han-Wen]

marius.vollmer@uni-dortmund.de writes:
> Han-Wen <hanwen@cs.uu.nl> 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?

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.

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> marius.vollmer@uni-dortmund.de writes:
> > Han-Wen <hanwen@cs.uu.nl> 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.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Mr. Peter Ivanyi]

Marius Vollmer wrote:

> 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.

Well, some of the memory checker programs would definitely signal an error
for the above code. As I remember, ANSI defines, that if a pointer goes
out of its range, then it becomes undefined. This have the unfortunate
consequence that

  block2+2000-1990

is not valid, you have to calculate the offset first, than use it with the
pointer. On the positive side though, I have never seen, heard any compiler
which takes this as a problem, only memory checker.

Hope it helps a little bit.

					Peter Ivanyi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Lynn Winebarger]

On Thursday 01 August 2002 11:40, Marius Vollmer wrote:
> 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.    
    That would be not, as it prints insane on my athlon-based
linux system.  Now if you tried block2 + 150, or block1 - 50,
we might have an interesting question.

Lynn

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Han-Wen Nienhuys]

marius.vollmer@uni-dortmund.de writes:
> > 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

I stand corrected, I looked it up in the N843 document
(http://www.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm), and you're
right.

> 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"?

However, that point is completely moot, since the binary search code
in heap_segment () (new GC: scm_find_heap_segment_containing_object)
is full of code that compares pointers outside their blocks.  Unless
that is scrapped (not), SCM_PTR_* can go.



-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Han-Wen Nienhuys]

hanwen@cs.uu.nl writes:
> However, that point is completely moot, since the binary search code
> in heap_segment () (new GC: scm_find_heap_segment_containing_object)
> is full of code that compares pointers outside their blocks.  Unless
> that is scrapped (not), SCM_PTR_* can go.

FWIW, that might be the reason that SCM doesn't use binsearch to
locate the heap segment.

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

>     That would be not, as it prints insane on my athlon-based
> linux system.

Argl.  It's me that is insane.  It should have been:

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

That is, I want to reliably test whether ptr is _outside_ of block1.

Sorry.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SCM_PTR_LE ?

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> However, that point is completely moot, since the binary search code
> in heap_segment () (new GC: scm_find_heap_segment_containing_object)
> is full of code that compares pointers outside their blocks.  Unless
> that is scrapped (not), SCM_PTR_* can go.

Ok, so you say that SCM_PTR_* is not used consistently and is
therefore broken anyway, right?  If that's the case (and I trust you
there) then SCM_PTR_* can really go.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel