Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91437 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2016-07-31 15:31 -0700 |
| Last post | 2016-08-08 22:12 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.c
Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-07-31 15:31 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-07-31 15:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:21 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 20:34 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 12:14 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 12:46 -0700
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 15:56 -0400
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 14:28 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 23:37 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 15:03 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-02 00:11 +0200
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 18:19 -0400
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-02 12:46 -0500
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-03 15:26 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 15:49 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:07 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 19:26 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:55 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-03 20:38 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 05:10 -0700
Re: Extending C with GC? Siri Cruise <chine.bleu@yahoo.com> - 2016-08-04 05:57 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 06:13 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 07:24 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 12:47 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:32 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 10:09 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 20:32 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-05 06:14 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:14 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-06 13:23 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:38 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 04:34 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 05:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:05 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:12 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:02 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 06:11 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:50 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 07:57 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 17:02 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:20 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 14:27 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:45 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 09:59 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 19:38 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 17:03 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 09:54 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-07 21:53 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 11:34 +0100
Re: Extending C with GC? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-07 12:06 +0000
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 14:10 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 15:38 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:32 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 23:44 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 16:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 01:42 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:56 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:20 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-08 09:39 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 02:30 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:15 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 01:24 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 02:08 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:49 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 03:28 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 12:14 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 07:37 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:56 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 08:11 +1200
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-07 22:19 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:23 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 14:29 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:36 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 15:04 -0700
Re: Extending C with GC? jameskuyper@verizon.net - 2016-08-07 15:19 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 00:04 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 16:20 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:21 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:35 +0100
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:13 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 11:53 -0700
Re: Extending C with GC? raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:58 +0000
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-10 07:05 -0700
Re: Extending C with GC? Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:29 -0400
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 21:15 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 08:57 -0700
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-07 15:37 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:58 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:26 +1200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 10:26 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:13 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:41 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 12:00 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 22:07 +1200
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-08 12:57 +0200
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:12 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:25 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 02:57 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 13:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 05:42 -0700
Re: Extending C with GC? Florian Weimer <fw@deneb.enyo.de> - 2016-08-07 11:49 +0200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:18 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:27 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 10:55 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:31 -0700
Re: Extending C with GC? James Kuyper <jameskuyper@verizon.net> - 2016-08-03 22:36 -0400
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 10:57 +0200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 04:09 -0700
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 14:01 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 07:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 08:57 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 09:19 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 12:30 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 15:21 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 16:50 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-05 07:31 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 16:01 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-04 21:00 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:26 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:37 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:52 +0100
Re: Extending C with GC? antispam@math.uni.wroc.pl - 2016-08-21 00:09 +0000
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-21 08:58 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-21 10:48 +0200
Re: Extending C with GC? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-08-21 19:58 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-22 08:46 -0700
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-26 02:24 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-26 13:37 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-27 00:41 +0200
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-28 06:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-05 10:06 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:26 +0100
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:11 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 17:43 +0200
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:28 -0700
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-04 17:11 -0500
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-01 07:45 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 08:49 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 09:06 -0700
Re: Extending C with GC? Aleksandar Kuktin <akuktin@gmail.com> - 2016-08-05 18:11 +0000
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-05 11:24 -0700
Re: Extending C with GC? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-08 22:12 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Florian Weimer <fw@deneb.enyo.de> |
|---|---|
| Date | 2016-08-07 11:49 +0200 |
| Message-ID | <87vazcoqmk.fsf@mid.deneb.enyo.de> |
| In reply to | #91811 |
* BartC: > Sure. If I wanted to try it out right now, I can just write: > > #include <gc.h> > .... > GC_MALLOC(N); > > if I use lccwin. With any other compiler, this won't work. This works on all major platforms if you install the Boehm/Demers/Weiser garbage collector. The header file is called <gc.h>, and it provides a GC_MALLOC macro, too. A lot of systems have pre-built these libraries, too.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-06 19:18 +0200 |
| Message-ID | <no565r$6as$1@dont-email.me> |
| In reply to | #91807 |
Le 06/08/2016 à 15:02, Ben Bacarisse a écrit : > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >>> >>> Ian Collins, do you have an answer? If there is a C compiler with >>> integrated GC, I'd like to have a look at its design. >>> >> Jacob's lcc-win. >> However it's closed source. The GC is one of the major competitive >> advantages, and you can't reasonably expect Jacob to give away his >> business's assets to satisfy your curiosity. > > Are you sure? To quote from an admittedly rather old copy of the > lcc-win's manual: > > "Lcc-win comes with an automatic memory manager (also called garbage > collector in the literature) written by Hans Boehm." > > Now it's quite possible a lot of work was needed to make the GC library > work with lcc-win, so maybe there is a significant business assets here, > but Rick could surely get 99% of the design just be reading the GC > sources. > Yes, there was some work involved, but I managed to get it all done and fix a bug that I sent to Mr Boehm. The sources are NOT closed source OF COURSE! How can I do a "closed source" stuff with source that aren't mine? ???? I did not modify the sources in any way as far as I remember.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-06 12:35 -0700 |
| Message-ID | <lnbn15y9la.fsf@kst-u.example.com> |
| In reply to | #91822 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> How can I do a "closed source" stuff with source that aren't mine?
>
> ????
It depends on the license. There are software licenses that that
permit use of source code and distribution of binaries without
redistributing source. (Apparently that doesn't apply in this case.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-06 19:27 +0200 |
| Message-ID | <no56mg$6as$3@dont-email.me> |
| In reply to | #91804 |
Le 06/08/2016 à 13:34, Malcolm McLean a écrit : > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >> >> Ian Collins, do you have an answer? If there is a C compiler with >> integrated GC, I'd like to have a look at its design. >> > Jacob's lcc-win. Yes > However it's closed source. Source can be bought. Price depends on whether you want distribution rights, or just the source, or just use it as a hobbbyist The GC is one of the major competitive > advantages, and you can't reasonably expect Jacob to give away his > business's assets to satisfy your curiosity. The source of the GC is PUBLIC DOMAIN and owned by Mr Bohm! ??? > You might be able to arrange some sort of deal whereby he licences > the technology to you, however. I can't negotiate arrangements on > Jacob's behalf, of course. > > You want a GC? Download lcc-win, take gc.dll and link to it. I have adapted (very slightly) to windows environment, and I fixed a small bug back then in 2005 or so... Enjoy!
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 10:55 -0700 |
| Message-ID | <834707eb-4080-45f4-a7a3-bd0bf08161c7@googlegroups.com> |
| In reply to | #91824 |
jacobnavia wrote: > Source can be bought. Price depends on whether you > want distribution rights, or just the source, or just use it as > a hobbbyist. How much is lcc source code for a hobbyist with no intent to distribute? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-06 12:31 -0700 |
| Message-ID | <lnfuqhy9rr.fsf@kst-u.example.com> |
| In reply to | #91824 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 06/08/2016 à 13:34, Malcolm McLean a écrit :
[...]
>> The GC is one of the major competitive
>> advantages, and you can't reasonably expect Jacob to give away his
>> business's assets to satisfy your curiosity.
>
> The source of the GC is PUBLIC DOMAIN and owned by Mr Bohm!
> ???
No, it's not public domain. Details may vary depending on the
relevant jurisdiction.
https://en.wikipedia.org/wiki/Public_domain
I just downloaded a recent copy of the source tarball for Boehm's
GC implementation. The README.QUICK file begins with several
copyright notices. Download and unpack
http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz
if you want to see the details.
(As far as I can tell, jacob's use of Boehm's GC implementation in
lcc-win is consistent with its license terms. I mention this to
forestall jacob's inevitable objections to anything I write about
him or his work.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-03 22:36 -0400 |
| Message-ID | <nnu9nh$nl8$1@dont-email.me> |
| In reply to | #91628 |
On 08/03/2016 06:26 PM, Keith Thompson wrote: ... > A GC system that depends on scanning memory and registers looking > for in-use addresses can also get false positives. > > A GC-aware program might build, say, a large binary tree in memory. > Let's say the root node is allocated at (void*)0xdeadbeef, and > the rest of the tree is accessible only via the root. The program > might then set its only copy of the root pointer to NULL with the > expectation that the whole tree will then be garbage-collected. > But if something that looks like the address of the root node happens > to be stored elsewhere, it might never be collected, resulting in > a memory leak. It has always been my understanding that GC inherently involves non-deterministic deallocation, partly because you can't be sure how long it will be until the collector notices that there are no remaining references, but mainly because it necessarily can incorrectly identify things as references to allocated memory that actually aren't. I've assumed that GC is used only by people who are comfortable with non-deterministic deallocation. I personally prefer the greater control over deallocation that is provided by malloc/free. > I'm fairly sure this is a well known issue. Perhaps there are > solutions I don't know about. I thought that the "solution" was simply to note that this is not likely to happen very often, and less often with larger memory spaces, and to decide that this low probability is acceptable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-04 10:57 +0200 |
| Message-ID | <nnv02k$dom$1@dont-email.me> |
| In reply to | #91633 |
On 04/08/16 04:36, James Kuyper wrote: > On 08/03/2016 06:26 PM, Keith Thompson wrote: > ... >> A GC system that depends on scanning memory and registers looking >> for in-use addresses can also get false positives. >> >> A GC-aware program might build, say, a large binary tree in memory. >> Let's say the root node is allocated at (void*)0xdeadbeef, and >> the rest of the tree is accessible only via the root. The program >> might then set its only copy of the root pointer to NULL with the >> expectation that the whole tree will then be garbage-collected. >> But if something that looks like the address of the root node happens >> to be stored elsewhere, it might never be collected, resulting in >> a memory leak. > > It has always been my understanding that GC inherently involves > non-deterministic deallocation, partly because you can't be sure how > long it will be until the collector notices that there are no remaining > references, but mainly because it necessarily can incorrectly identify > things as references to allocated memory that actually aren't. I've > assumed that GC is used only by people who are comfortable with > non-deterministic deallocation. > I personally prefer the greater control over deallocation that is > provided by malloc/free. malloc/free are also (in most implementations) non-deterministic in some aspects. In particular, their run times can be very hard to predict, and you never know in advance if malloc will succeed or not. You know that when you call free, memory will in some sense be "freed" - but you don't know whether or not you will be able to use that memory in the next malloc. GC adds more non-determinism - you have no idea when memory will be freed, and it may never be freed at all. (Cyclic references are a killer.) But it gives you extra convenience, and can often save time (certainly saving developer time, perhaps saving run time). For much of my work (small systems embedded programming), the non-determinism of standard malloc/free is too much - dynamic memory allocation is avoided whenever possible. It is usually better to have static allocation with the memory sized to suit the worst case, than to have the risk of malloc failures or heap fragmentation problems. > >> I'm fairly sure this is a well known issue. Perhaps there are >> solutions I don't know about. > > I thought that the "solution" was simply to note that this is not likely > to happen very often, and less often with larger memory spaces, and to > decide that this low probability is acceptable. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-04 04:09 -0700 |
| Message-ID | <bf86c23f-565f-475c-9843-4733f66ff39c@googlegroups.com> |
| In reply to | #91636 |
On Thursday, August 4, 2016 at 9:58:08 AM UTC+1, David Brown wrote: > > For much of my work (small systems embedded programming), the > non-determinism of standard malloc/free is too much - dynamic memory > allocation is avoided whenever possible. It is usually better to have > static allocation with the memory sized to suit the worst case, than to > have the risk of malloc failures or heap fragmentation problems. > Calls to malloc() usually fit one of three patterns Caller frees: ptr = malloc(N); ... free(ptr); Object constructor / destructor: ptr = constuctor(params); // allocates an object ... // no change to ptr's memory internals destructor(ptr); // destroys it Graph creation, manipulation and destruction: node = makenode(); // all nodes small and of identical size while(condition) node->add( makenode()); while(othercondition) node->release(childnodeid); ... destroyallnodes(): The first two you can service with a stack-based allocator, as long as you are extremely careful with the second pattern. The third pattern you can service with a fixed block allocator. Both of those allocators run a lot faster than malloc(), and neither is subject to fragmentation. However the fixed block allocator can be a bit of a memory hog if you don't need most of the blocks for most of the runtime of the program, and you need several different block sizes so more than one allocator.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-04 14:01 +0200 |
| Message-ID | <nnvaqt$faq$1@dont-email.me> |
| In reply to | #91639 |
On 04/08/16 13:09, Malcolm McLean wrote: > On Thursday, August 4, 2016 at 9:58:08 AM UTC+1, David Brown wrote: >> >> For much of my work (small systems embedded programming), the >> non-determinism of standard malloc/free is too much - dynamic memory >> allocation is avoided whenever possible. It is usually better to have >> static allocation with the memory sized to suit the worst case, than to >> have the risk of malloc failures or heap fragmentation problems. >> > Calls to malloc() usually fit one of three patterns > > Caller frees: > > ptr = malloc(N); > ... > free(ptr); > > Object constructor / destructor: > > ptr = constuctor(params); // allocates an object > ... // no change to ptr's memory internals > destructor(ptr); // destroys it > > Graph creation, manipulation and destruction: > > node = makenode(); // all nodes small and of identical size > while(condition) > node->add( makenode()); > while(othercondition) > node->release(childnodeid); > > ... > destroyallnodes(): > > > The first two you can service with a stack-based allocator, as long as > you are extremely careful with the second pattern. > The third pattern you can service with a fixed block allocator. > > Both of those allocators run a lot faster than malloc(), and neither is subject > to fragmentation. However the fixed block allocator can be a bit of a memory > hog if you don't need most of the blocks for most of the runtime of the > program, and you need several different block sizes so more than one allocator. > That may be your experience, but it is not /my/ experience. A stack-based allocator is close to useless. If you know the size of the object you are dealing with, you just make the object a local variable - there is no need to mess about with allocators and an extra layer of indirection. If you don't know the size, the chances are high that it is an array and a VLA will do the job. Failing that, alloca() already exists. Stack allocation has the advantage of speed and simplicity, you don't need to check the return (for alloca) or have other error checking code, there is no fragmentation, there is no overhead to track the heap, and there is no need to "free" anything. But stack space can be limited (depending on your target system, OS, configuration, etc.), and if something /does/ go wrong, it usually goes spectacularly wrong without scope for testing or recovery. As for your idea that most dynamic memory usage is either temporary and local to a function, or part of a graph - well, I think you spend a bit too much time working with graphs. You seem to see them everywhere. You are, of course, correct that if you would be dynamically allocating memory in blocks of a fixed (at compile time) size, such as may be the case for some data structures, then a specialised block or pool allocator will be more efficient than a general heap manager. But that does not help for dynamic memory allocations of varying sizes - buffers, strings, file input and output, etc.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-04 07:52 -0700 |
| Message-ID | <7c65ec51-f06f-4eb3-ae0d-828bdbfc870d@googlegroups.com> |
| In reply to | #91633 |
On Wednesday, August 3, 2016 at 9:36:39 PM UTC-5, James Kuyper wrote: > It has always been my understanding that GC inherently involves > non-deterministic deallocation, partly because you can't be sure how > long it will be until the collector notices that there are no remaining > references, but mainly because it necessarily can incorrectly identify > things as references to allocated memory that actually aren't. The latter can *never* happen in languages which are designed for GC; in the .NET and Java frameworks, it is imperative that the type system know at all times the whereabouts of every single reference that exists anywhere in the universe, save for the fact that (at least in .NET) it is possible to "pin" an object, and it is acceptable to hold pointers to a pinned object without the GC knowing about them, provided that no such pointer is ever used after the object is unpinned. Note that .NET is not designed to handle efficiently the possibility of many objects being pinned for an extended period of time; such a situation may severely degrade performance. Incidentally, in a framework which does not allow the equivalent of lvalue references to structures that contain a mixture of primitives and object references (.NET does allow such lvalue references, while Java does not), the type system could place all object references at the start of an object's allocation, followed by the object header and then all primitives contained therein. References to an object would not identify the start of its allocation, but would instead identify the header. In such a design, a garbage collector could quickly traverse a tree of references since all the references stored within each object would be kept consecutively. In .NET things are a little more complicated, since it is necessary that a structure containing a mixture of references and primitive types be stored in one contiguous chunk of memory. The type system maintains maps of which parts of a structure hold references vs primitives, but the design is more complicated than it would be if such maps were not required.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-04 08:57 -0700 |
| Message-ID | <kfnvazgil16.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91628 |
Keith Thompson <kst-u@mib.org> writes: > Keith Thompson <kst-u@mib.org> writes: >> luser droog <luser.droog@gmail.com> writes: >>> In a recent thread that touched upon closures, it was made apparent >>> that automatic storage reclamation would be a practical necessity >>> to support closures. >>> >>> So how would C work with a garbage collector? How do existing >>> extensions work? Is there a new allocator function to allow a >>> "mixed" style, where you manually free the things that are easy >>> and rely on the GC for the things that are hard? Or does it >>> take-over malloc(), if so what does free() do? >>> >>> Since I use C primarily as the implementation language for other >>> programming languages, I'd love to stop writing gc code. >> >> There is a narrow technical point that implies that garbage >> collection is incompatible with conformance to the C standard. >> >> GC depends on the ability to detect that a chunk of memory is no >> longer in use, and can be recovered. There are various methods >> to do this, but basically if there's currently nothing pointing to >> a chunk of memory, it's considered safe to assume that that chunk >> can be reclaimed. > > [snip discussion of ways a pointer value can be "hidden" from a GC > system] > > There's also an inverse problem, though it's not as severe. > > A GC system that depends on scanning memory and registers looking > for in-use addresses can also get false positives. > > A GC-aware program might build, say, a large binary tree in memory. > Let's say the root node is allocated at (void*)0xdeadbeef, and > the rest of the tree is accessible only via the root. The program > might then set its only copy of the root pointer to NULL with the > expectation that the whole tree will then be garbage-collected. > But if something that looks like the address of the root node happens > to be stored elsewhere, it might never be collected, resulting in > a memory leak. If you're interested, the literature usually refers to systems that operate like this as having "ambiguous roots". > I believe that GC systems for some languages other than C can > deal with this, but I don't know how a C garbage collector could > avoid this problem in all cases. Perhaps a compiler could provide > information that the GC can access at run time that tells it which > objects are actually pointers -- but I don't know (a) whether > compilers actually do this, or (b) whether it's even possible > in general. To avoid dealing with ambiguous roots, the language needs to operate in an environment where: one, the type of every memory cell is known (so the collector knows whether it's a pointer or not); two, pointers cannot be "disguised" so that they are stored in places that the collector doesn't know about. I think it would be very hard for a C implementation to satisfy the first property, and essentially impossible to satisfy the second property, assuming full C is allowed. There just are too many ways to hide a pointer from the collector. Even just the problem of knowing which memory cells contain undisguised pointers isn't easy, because of things like unions, unitialized variables, and how to deal with memory that has been malloc'ed (which, among other things, may have types that change over time). > I'm fairly sure this is a well known issue. Perhaps there are > solutions I don't know about. GC in the face of ambiguous roots has gotten a lot of attention, and is generally accepted as workable in a practical engineering sense. The issue of how much memory is "lost" due to false positives has been studied and measured (my memory is that the amount is "small", maybe in the neighborhood of 10%, but that is a very fuzzy memory so take it for what it's worth). In terms of avoiding the problem of ambiguous roots, something that has been tried in another programming language is to have a "safe subset" where collection can be done reliably, and "unsafe features" that must be used with caution to avoid blowing up the collector. That situation is superficially like C, but I don't know how workable (or unworkable) it would be to look for a "safe subset" of C where collection could be done without ambiguity. The problem of course is that any "safe subset" of C might be so limited that it would never be used. Since a conservative collector (ie, that deals with ambiguous roots) seems to work fairly well, other avenues probably won't get much attention.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-04 09:19 -0700 |
| Message-ID | <ef8cdc4a-bca2-443e-93d7-3e94a78c15f1@googlegroups.com> |
| In reply to | #91654 |
On Thursday, August 4, 2016 at 10:58:07 AM UTC-5, Tim Rentsch wrote: > I think > it would be very hard for a C implementation to satisfy the first > property, and essentially impossible to satisfy the second > property, assuming full C is allowed. One could define a subset of C which could run a very large fraction of C programs without difficulty, if one were willing to add a rule that said that pointers could only be written directly using pointer lvalues, indirectly using using pointer-to-pointer rvalues, or copied in a single step using memcpy/memmove; any other means of writing to a pointer would invalidate it. Such a thing could be handled practically by having a tag bit associated with each memory word that indicates whether it holds a pointer; an attempt to load a pointer rvalue would trap unless either the rvalue was all-bits-zero or the bit was set, and storing a memory word other than as described above would trap. Some strictly-conforming programs would fail when run on such an implementation, but many would run just fine, and such an implementation could securely validate all memory accesses--a useful feature whether or not one uses garbage collection. A slight variation on the above, which would bring things closer to full conformance, would require that sizeof(any pointer) be equal to 1, but type "char" would be capable of holding either a number or a pointer, with a "hidden" bit that identified which it held. Using any arithmetic operator on a "char" value would clear the "is a pointer" bit, and there would be no means via which user code could set that bit except via operations that yield validated pointers. Weakening the "only" language defined by the C Standard as described above would make the language totally useless for many kinds of system programming (which need the ability to synthesize pointers out of thin air) but a Standard-defined subset of C which would not support system programming but would support sandboxing could be extremely useful for many other purposes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-04 12:30 -0700 |
| Message-ID | <lnd1lo1gd4.fsf@kst-u.example.com> |
| In reply to | #91656 |
supercat@casperkitty.com writes:
[...]
> A slight variation on the above, which would bring things closer to full
> conformance, would require that sizeof(any pointer) be equal to 1, but
> type "char" would be capable of holding either a number or a pointer,
> with a "hidden" bit that identified which it held. Using any arithmetic
> operator on a "char" value would clear the "is a pointer" bit, and there
> would be no means via which user code could set that bit except via
> operations that yield validated pointers.
You suggest (for this subset) requiring all pointers to have a size of 1
bytes, and type `char` to be able to hold a pointer? Why `char`? Why
not, say, `uintptr_t` (with whatever size it happens to have, typically
4 or 8)?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-04 15:21 -0700 |
| Message-ID | <02caff7d-863c-4de0-a849-6a4289a1eac3@googlegroups.com> |
| In reply to | #91669 |
On Thursday, August 4, 2016 at 2:30:58 PM UTC-5, Keith Thompson wrote: > supercat writes: > > A slight variation on the above, which would bring things closer to full > > conformance, would require that sizeof(any pointer) be equal to 1, but > > type "char" would be capable of holding either a number or a pointer, > > with a "hidden" bit that identified which it held. Using any arithmetic > > operator on a "char" value would clear the "is a pointer" bit, and there > > would be no means via which user code could set that bit except via > > operations that yield validated pointers. > > You suggest (for this subset) requiring all pointers to have a size of 1 > bytes, and type `char` to be able to hold a pointer? Why `char`? Why > not, say, `uintptr_t` (with whatever size it happens to have, typically > 4 or 8)? Suppose one stores a bunch of pointers is a malloc'ed region and then arbitrarily rearranges all the unsigned char values within that region. If each "unsigned char" is large enough to hold an entire pointer, then the pointers would remain identifiable even after being scrambled. If the "unsigned char" values aren't big enough to hold pointers, I'm see no practical way via which an implementation could identify which parts of which pointers belonged together.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-04 16:50 -0700 |
| Message-ID | <lnmvksytzb.fsf@kst-u.example.com> |
| In reply to | #91688 |
supercat@casperkitty.com writes:
> On Thursday, August 4, 2016 at 2:30:58 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > A slight variation on the above, which would bring things closer to full
>> > conformance, would require that sizeof(any pointer) be equal to 1, but
>> > type "char" would be capable of holding either a number or a pointer,
>> > with a "hidden" bit that identified which it held. Using any arithmetic
>> > operator on a "char" value would clear the "is a pointer" bit, and there
>> > would be no means via which user code could set that bit except via
>> > operations that yield validated pointers.
>>
>> You suggest (for this subset) requiring all pointers to have a size of 1
>> bytes, and type `char` to be able to hold a pointer? Why `char`? Why
>> not, say, `uintptr_t` (with whatever size it happens to have, typically
>> 4 or 8)?
>
> Suppose one stores a bunch of pointers is a malloc'ed region and then
> arbitrarily rearranges all the unsigned char values within that region.
> If each "unsigned char" is large enough to hold an entire pointer, then
> the pointers would remain identifiable even after being scrambled. If
> the "unsigned char" values aren't big enough to hold pointers, I'm see
> no practical way via which an implementation could identify which parts
> of which pointers belonged together.
Nor do I. But IMHO the solution is either (a) use a language other
than C that doesn't let you scramble pointer values like that (or
at least that doesn't expect them to remain as valid pointers after
you unscramble them), or (b) don't scramble pointers like that and
expect GC to continue to work.
Even if your proposal solved the problems, I think it's massive
overkill. You might as well define a new language and not call it C.
(Allowing sizeof (void*) == 1 is compatible with C as it now exists;
requiring it is not, and is certainly not compatible with most
current C implementations.)
If your point is that this is the kind of language change you'd
have to make GC work 100% reliably with C, then it's still not
enough. You can scramble the bits making up the representation
of the pointers as easily as you can scramble the bytes; see the
doubly-linked list xor trick discussed here recently.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-05 07:31 -0700 |
| Message-ID | <1386d676-3f32-4802-9ccb-7c3402cc7a08@googlegroups.com> |
| In reply to | #91694 |
On Thursday, August 4, 2016 at 6:50:25 PM UTC-5, Keith Thompson wrote: > Nor do I. But IMHO the solution is either (a) use a language other > than C that doesn't let you scramble pointer values like that (or > at least that doesn't expect them to remain as valid pointers after > you unscramble them), or (b) don't scramble pointers like that and > expect GC to continue to work. What I described was the simplest set of changes I could see which would provide reliable garbage-collection while still remaining compatible with a significant amount of C code. > Even if your proposal solved the problems, I think it's massive > overkill. You might as well define a new language and not call it C. > (Allowing sizeof (void*) == 1 is compatible with C as it now exists; > requiring it is not, and is certainly not compatible with most > current C implementations.) I gave two possibilities--either disallow the use of character types to manipulate the storage underlying pointers (in which case sizeof(void*) could be anything) or make characters big enough that using character types to manipulate pointers won't "split" them. > If your point is that this is the kind of language change you'd > have to make GC work 100% reliably with C, then it's still not > enough. You can scramble the bits making up the representation > of the pointers as easily as you can scramble the bytes; see the > doubly-linked list xor trick discussed here recently. As I described it, each character would have a bit which indicates whether it is usable as a pointer; manipulating a pointer as though it were a number would yield a number that could no longer be used as a pointer (trying to use it as one would likely trap).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-05 16:01 -0700 |
| Message-ID | <kfnk2fuhlbb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91656 |
supercat@casperkitty.com writes: > On Thursday, August 4, 2016 at 10:58:07 AM UTC-5, Tim Rentsch wrote: >> I think >> it would be very hard for a C implementation to satisfy the first >> property, and essentially impossible to satisfy the second >> property, assuming full C is allowed. > > [.. overly verbose contorted writing ..] "Now who can argue with that?" - Olson Johnson in Blazing Saddles
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-04 21:00 +0200 |
| Message-ID | <no03cf$560$1@dont-email.me> |
| In reply to | #91654 |
Le 04/08/2016 à 17:57, Tim Rentsch a écrit : > To avoid dealing with ambiguous roots, the language needs to > operate in an environment where: one, the type of every memory > cell is known (so the collector knows whether it's a pointer or > not); two, pointers cannot be "disguised" so that they are > stored in places that the collector doesn't know about. I think > it would be very hard for a C implementation to satisfy the first > property, and essentially impossible to satisfy the second > property, assuming full C is allowed. That environment can be provided by the compiler. At each line of code there is the Current scope. That scope and all other above it, contain data that has types, of course, and all pointers are known. The compiler can generate a table of locations within the function, that points to the table of all valid pointers in the program and their addresses. Note that only the pointers marked as GC-pointers will be included in the tables. All other pointers are not concerned by the GC. The malloc/free system continues to work as always and you can write 0xdeadbeef into any of those pointers with a simple cast. GC-pointers however, are not allowed to be cast into anything else but a GC-pointer of (maybe) a different type. GC: 1) From the current frame, mark as used all pointers in the current function. 2) Use the stack unwind info to retrieve the calling function, mark those until the global scope is reached and mark all that one too. 3) Do this for each thread. 4) Unmarked memory is free. Note that the info can also be used by a debugger or the user itself if the language provides a run time interface. A stack trace of the program becomes easy to do... Note that this doesn't imply ANY change to the language besides the introduction of the GC-interface names.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-04 20:26 +0100 |
| Message-ID | <87lh0cs5cj.fsf@bsb.me.uk> |
| In reply to | #91663 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 04/08/2016 à 17:57, Tim Rentsch a écrit :
>> To avoid dealing with ambiguous roots, the language needs to
>> operate in an environment where: one, the type of every memory
>> cell is known (so the collector knows whether it's a pointer or
>> not); two, pointers cannot be "disguised" so that they are
>> stored in places that the collector doesn't know about. I think
>> it would be very hard for a C implementation to satisfy the first
>> property, and essentially impossible to satisfy the second
>> property, assuming full C is allowed.
>
> That environment can be provided by the compiler. At each line of code
> there is the Current scope. That scope and all other above it, contain
> data that has types, of course, and all pointers are known. The
> compiler can generate a table of locations within the function, that
> points to the table of all valid pointers in the program and their
> addresses.
void f(void *vp)
{
union { int i; void *p; } u.i = 42;
if (g()) u.p = vp;
...
}
What pointers need to be in the table here?
> Note that only the pointers marked as GC-pointers will be included in
> the tables.
How is this achieved? What lets you identify GC-pointers from
non-GC-pointers? Are you suggesting tracking pointer assignments at
run-time?
> All other pointers are not concerned by the GC. The
> malloc/free system continues to work as always and you can write
> 0xdeadbeef into any of those pointers with a simple cast.
>
> GC-pointers however, are not allowed to be cast into anything else but
> a GC-pointer of (maybe) a different type.
You say below that your scheme does not imply ANY change to the language
(besides the GC interface names) but this looks like a language change
rule to me.
> GC:
> 1) From the current frame, mark as used all pointers in the current
> function.
>
> 2) Use the stack unwind info to retrieve the calling function, mark
> those until the global scope is reached and mark all that one too.
>
> 3) Do this for each thread.
>
> 4) Unmarked memory is free.
What about pointers in pointed-to objects, particularly malloc'd ones?
> Note that the info can also be used by a debugger or the user itself
>if the language provides a run time interface. A stack trace of the
>program becomes easy to do...
>
> Note that this doesn't imply ANY change to the language besides the
> introduction of the GC-interface names.
You imply there is some new kind of pointer (called a GC-pointer) which
may not be cast in certain ways. That sounds like a language change to
me.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web