Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23460 > unrolled thread

Strange C developments

Back to article view | Back to comp.lang.c

Contents

  Strange C developments Jase Schick <nospam@nospam.com> - 2012-07-20 21:14 +0000
    Re: Strange C developments Les Cargill <lcargill99@comcast.com> - 2012-07-20 18:03 -0500
    Re: Strange C developments "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-20 16:03 -0700
      Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 15:11 -0700
      Re: Strange C developments tom st denis <tom@iahu.ca> - 2012-08-02 06:08 -0700
        Re: Strange C developments Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-02 21:23 +0200
          Re: Strange C developments tom st denis <tom@iahu.ca> - 2012-08-03 04:13 -0700
            Re: Strange C developments Noob <root@127.0.0.1> - 2012-08-03 13:19 +0200
            Re: Strange C developments Anders Wegge Keller <wegge@wegge.dk> - 2012-08-03 13:31 +0200
            Re: Strange C developments Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-03 23:47 +0200
        Re: Strange C developments gwowen <gwowen@gmail.com> - 2012-08-03 02:20 -0700
    Re: Strange C developments Rui Maciel <rui.maciel@gmail.com> - 2012-07-21 01:25 +0100
    Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-20 19:38 -0500
    Re: Strange C developments Nobody <nobody@nowhere.com> - 2012-07-21 10:32 +0100
      Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-21 09:31 -0500
        Re: Strange C developments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 17:38 +0100
          Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-21 12:58 -0500
          Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 11:42 -0700
            Re: Strange C developments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 20:13 +0100
              Re: Strange C developments Nobody <nobody@nowhere.com> - 2012-07-21 20:48 +0100
                Re: Strange C developments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 23:32 +0100
    Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-21 11:43 +0200
      Re: Strange C developments Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-07-21 10:23 +0000
        Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-21 13:01 +0200
          Re: Strange C developments gordonb.y4pdz@burditt.org (Gordon Burditt) - 2012-07-21 08:57 -0500
            Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-21 10:40 -0500
            Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-21 19:03 +0200
              Re: Strange C developments gordonb.5rhpu@burditt.org (Gordon Burditt) - 2012-07-22 02:08 -0500
                Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-22 12:32 +0200
                  Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-22 08:26 -0500
              Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-24 01:23 -0700
                Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 05:36 -0700
                  Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:04 -0700
                Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-24 09:55 -0500
                  Re: Strange C developments 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-02 06:44 -0700
                    Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-08-03 08:48 -0500
            Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-21 19:06 +0200
              Re: Strange C developments gordonb.ibds9@burditt.org (Gordon Burditt) - 2012-07-22 02:28 -0500
                Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-22 12:30 +0200
                Re: Strange C developments Philip Lantz <prl@canterey.us> - 2012-07-24 00:58 -0700
          Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-24 01:13 -0700
        Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 05:44 -0700
          Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 15:31 -0700
            Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 16:59 -0700
              Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 23:46 -0700
                Re: Strange C developments "io_x" <a@b.c.invalid> - 2012-07-22 10:37 +0200
                  Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-22 03:28 -0700
                  Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-22 09:05 -0500
                  Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-24 02:10 -0700
                    Re: Strange C developments "io_x" <a@b.c.invalid> - 2012-07-27 20:47 +0200
                      Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:09 -0700
                        Re: Strange C developments "BartC" <bc@freeuk.com> - 2012-07-30 13:05 +0100
                          Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-08-03 10:45 -0500
                        Re: Strange C developments "io_x" <a@b.c.invalid> - 2012-07-30 16:52 +0200
                          Re: Strange C developments "io_x" <a@b.c.invalid> - 2012-07-30 18:26 +0200
                        Re: Strange C developments Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-03 12:12 -0700
                          Re: Strange C developments "BartC" <bc@freeuk.com> - 2012-08-04 12:18 +0100
                            Re: Strange C developments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-08-10 09:50 +0300
                  Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:19 -0700
                    Re: Strange C developments "io_x" <a@b.c.invalid> - 2012-09-09 12:06 +0200
                  Re: Strange C developments Kaz Kylheku <kaz@kylheku.com> - 2012-09-09 05:25 +0000
            Re: Strange C developments Melzzzzz <mel@zzzzz.com> - 2012-07-22 02:48 +0200
            Re: Strange C developments William Ahern <william@wilbur.25thandClement.com> - 2012-07-21 21:45 -0700
              Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-22 02:40 -0700
                Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-22 10:38 -0500
            Re: Strange C developments William Ahern <william@wilbur.25thandClement.com> - 2012-07-21 22:38 -0700
              Re: Strange C developments jacob navia <jacob@spamsink.net> - 2012-07-22 08:43 +0200
              Re: Strange C developments "BartC" <bc@freeuk.com> - 2012-07-22 11:24 +0100
                Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-08-03 09:09 -0500
                  Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-08-03 16:54 -0500
            Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 23:16 -0700
              Re: Strange C developments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-22 17:50 +0300
                Re: Strange C developments BGB <cr88192@hotmail.com> - 2012-07-22 11:27 -0500
                  Re: Strange C developments Ike Naar <ike@iceland.freeshell.org> - 2012-07-22 20:55 +0000
                    Re: Strange C developments Philip Lantz <prl@canterey.us> - 2012-07-24 00:56 -0700
                      Re: Strange C developments Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-24 01:57 -0700
                Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:20 -0700
        Re: Strange C developments Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 15:13 -0700
    Re: Strange C developments John Bode <jfbode1029@gmail.com> - 2012-07-23 14:59 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#23460 — Strange C developments

Hi Can anyone explain why C has added support for pthreads, while NOT 
adding support for garbage collection? Convenient memory management would 
be a much greater enhancement than replicating a perfectly good existing 
library it seems to me.

Jase

[toc] | [next] | [standalone]

#23462

Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection?

GC in 'C' is a non sequitur.

> Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>
> Jase
>

I think you want Java, then.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#23465

On Jul 20, 10:14 pm, Jase Schick <nos...@nospam.com> wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.

Interestingly, Apple just killed garbage collection in their Objective-
C compilers and never moved support for GC to the iPhone.
So someone there thinks that garbage collection isn't _that_ useful.
And sorry to say, but C wasn't designed with garbage collection in
mind.

[toc] | [prev] | [next] | [standalone]

#23526

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:

> On Jul 20, 10:14 pm, Jase Schick <nos...@nospam.com> wrote:
>> Hi Can anyone explain why C has added support for pthreads, while NOT
>> adding support for garbage collection? Convenient memory management would
>> be a much greater enhancement than replicating a perfectly good existing
>> library it seems to me.
>
> Interestingly, Apple just killed garbage collection in their Objective-
> C compilers and never moved support for GC to the iPhone.
> So someone there thinks that garbage collection isn't _that_ useful.

I  believe that  is consequent  to a  confluence of  (a)  wanting the
environments on  the iPhone and MacOS  to be the same,  (b) needing a
certain level of real-time response on the iPhone, and (c) adopting a
different approach to resource management that allows reference
counting to be used rather than general GC.

It isn't hard to write a high-performance, general-purpose GC.  It's
much harder to write a high-performance GC that observes severe
real-time constraints.

> And sorry to say, but C wasn't designed with garbage collection in
> mind.

But that doesn't precude GC being either feasible or practical in
a C environment.

[toc] | [prev] | [next] | [standalone]

#24128

On Jul 20, 7:03 pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> On Jul 20, 10:14 pm, Jase Schick <nos...@nospam.com> wrote:
>
> > Hi Can anyone explain why C has added support for pthreads, while NOT
> > adding support for garbage collection? Convenient memory management would
> > be a much greater enhancement than replicating a perfectly good existing
> > library it seems to me.
>
> Interestingly, Apple just killed garbage collection in their Objective-
> C compilers and never moved support for GC to the iPhone.
> So someone there thinks that garbage collection isn't _that_ useful.
> And sorry to say, but C wasn't designed with garbage collection in
> mind.

Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically.

That sort of syntax would make certain functions a bit easier to work
with, infinitely more useful would be something like

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.

[toc] | [prev] | [next] | [standalone]

#24145

Am 02.08.2012 15:08, schrieb tom st denis:
> Syntactically it'd be pretty easy to have something like
> 
> heap int *p;
> 
> where "heap" defaults to init it to NULL and then at the end a call to
> free() is made automatically.
> 
> That sort of syntax would make certain functions a bit easier to work
> with, infinitely more useful would be something like
> 
> heap int foo[34]; // or whatever array size
> 
> Where it allocates "foo" off the heap (via calloc) automagically,
> raising a signal if it fails, and then when the function returns it
> calls free() on it.
> 
> That would be very useful for small stackframe applications.

Why would you need such a "heap" marker syntactically?

For your first example for the pointer (syntactically) I would just do

int foo[1];

An implementation could just decide to allocate "auto" arrays on the
heap, and free everything at the end of the liftime of the variable. You
don't have to add a jota to the syntax of C for that.

The downside of such a "heap" approach for array allocation is that the
implementation of setjmp/longjmp would be come a bit more complicated.
You can't just re-adjust the stack pointer but you'd have to re-invent a
mechanism that "free"s all the allocated arrays on the way down, once
you jump to a different function stack. Isn't completely trivial.

Jens


  * Unbekannt - erkannt
  * Englisch
  * Deutsch

  * Englisch
  * Deutsch

 <javascript:void(0);> <#>

[toc] | [prev] | [next] | [standalone]

#24163

On Aug 2, 3:23 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
> Am 02.08.2012 15:08, schrieb tom st denis:
>
>
>
>
>
>
>
>
>
> > Syntactically it'd be pretty easy to have something like
>
> > heap int *p;
>
> > where "heap" defaults to init it to NULL and then at the end a call to
> > free() is made automatically.
>
> > That sort of syntax would make certain functions a bit easier to work
> > with, infinitely more useful would be something like
>
> > heap int foo[34]; // or whatever array size
>
> > Where it allocates "foo" off the heap (via calloc) automagically,
> > raising a signal if it fails, and then when the function returns it
> > calls free() on it.
>
> > That would be very useful for small stackframe applications.
>
> Why would you need such a "heap" marker syntactically?
>
> For your first example for the pointer (syntactically) I would just do
>
> int foo[1];
>
> An implementation could just decide to allocate "auto" arrays on the
> heap, and free everything at the end of the liftime of the variable. You
> don't have to add a jota to the syntax of C for that.
>
> The downside of such a "heap" approach for array allocation is that the
> implementation of setjmp/longjmp would be come a bit more complicated.
> You can't just re-adjust the stack pointer but you'd have to re-invent a
> mechanism that "free"s all the allocated arrays on the way down, once
> you jump to a different function stack. Isn't completely trivial.

Are there real people who use setjmp()/etc in everyday code?  I've
never once used them despite all the oddball places my code has been
found.

And while the compiler could automagically decide to take from the
heap for auto variables it would be nice for that to be more manual.

Tom

[toc] | [prev] | [next] | [standalone]

#24164

tom st denis wrote:

> Are there real people who use setjmp()/etc in everyday code?  I've
> never once used them despite all the oddball places my code has been
> found.

IJG's libjpeg uses longjmp to bail out on error o_O
(I suppose the author didn't want to propagate errors.)
Kinda hairy, in my opinion.

[toc] | [prev] | [next] | [standalone]

#24165

tom st denis <tom@iahu.ca> writes:

> Are there real people who use setjmp()/etc in everyday code?  I've
> never once used them despite all the oddball places my code has been
> found.

    if (timeout) {
        signal (SIGALRM, alarm_int);
        alarm (timeout) ;
    }
    if (setjmp (timrenv) == 0) {
        retval = routine (param1, param2) ;
        /* this is a normal return */
    } else {
        /* we come here after a timeout */

 Our codebase have several places where timeouts are handled by
setjmp/longjmp as the snippet above. The alarm handler finish with a
longjmp(). This is legacy code, originally deployed on Xenix. I've
been lead to beleive that this was the only reliable way of handling
socket timeouts on that platform.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#24177

Am 03.08.2012 13:13, schrieb tom st denis:
> On Aug 2, 3:23 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
>> Why would you need such a "heap" marker syntactically?
>>
>> For your first example for the pointer (syntactically) I would just do
>>
>> int foo[1];
>>
>> An implementation could just decide to allocate "auto" arrays on the
>> heap, and free everything at the end of the liftime of the variable. You
>> don't have to add a jota to the syntax of C for that.
>>
>> The downside of such a "heap" approach for array allocation is that the
>> implementation of setjmp/longjmp would be come a bit more complicated.
>> You can't just re-adjust the stack pointer but you'd have to re-invent a
>> mechanism that "free"s all the allocated arrays on the way down, once
>> you jump to a different function stack. Isn't completely trivial.
> 
> Are there real people who use setjmp()/etc in everyday code?  I've
> never once used them despite all the oddball places my code has been
> found.

youp, I do

But really don't think of every day's programmer for that, but e.g
people that implement C++'s try/catch mechanism or other such stuff
for higher languages in C.

Said otherwise, deleting setjmp/longjmp from the language is certainly
not an option. It is a core feature.

> And while the compiler could automagically decide to take from the
> heap for auto variables it would be nice for that to be more manual.

perhaps

I was trying to think on a more realistic line. If you'd want such a
feature, there is nothing essential that would hinder you to implement
it first for auto variables without letting a choice to the
programmer. This can be done without extending the language. It would
have advantages (namely avoid stackoverflow, namely for VLA) and
downsides (a bit of performance loss).

If then you have a system that implements this, runs smoothly without
a bug for some time on a large variety of systems and code, you may
even propose the extension to allow to specify that explicitly, why
not.

Jens

[toc] | [prev] | [next] | [standalone]

#24162

On Aug 2, 2:08 pm, tom st denis <t...@iahu.ca> wrote:

> Syntactically it'd be pretty easy to have something like
>
> heap int *p;
>
> where "heap" defaults to init it to NULL and then at the end a call to
> free() is made automatically... infinitely more useful would be something like
>
> heap int foo[34]; // or whatever array size
>
> Where it allocates "foo" off the heap (via calloc) automagically,
> raising a signal if it fails, and then when the function returns it
> calls free() on it.
>
> That would be very useful for small stackframe applications.

Replace "signal" with exception, and you've just (re-)invented the key
point of of C++ RAII?  Personally, I find resource management with
RAII far more convenient than GC -- though I appreciate that GC has
some advantages -- as it works for more than memory.

In fact, RAII is the single biggest thing that makes C++'s esoteric
horrors worth putting up with.

[toc] | [prev] | [next] | [standalone]

#23468

Jase Schick wrote:

> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.

Why do you believe that garbage collection should be added to the C 
standard?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#23470

On 7/20/2012 4:14 PM, Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>

more people can agree on the behavior of a threading library than they 
can on the behavior of a GC library?...

a few possible issues with a GC:
precise or conservative GC?
how does it represent references?
how does it interact with stack variables, global variables, or malloc?
does it simply behave like malloc, or does it also preserve type 
information?
...

some of these issues would need to be addressed, and as-is, people get 
by ok either using or implementing garbage-collection via libraries.

[toc] | [prev] | [next] | [standalone]

#23478

On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:

> Hi Can anyone explain why C has added support for pthreads, while NOT 
> adding support for garbage collection?

GC requires a "walled garden", which C isn't.

You can't just "add support" for GC, you have to design the language
around the ability to enumerate references.

[toc] | [prev] | [next] | [standalone]

#23485

On 7/21/2012 4:32 AM, Nobody wrote:
> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>
>> Hi Can anyone explain why C has added support for pthreads, while NOT
>> adding support for garbage collection?
>
> GC requires a "walled garden", which C isn't.
>
> You can't just "add support" for GC, you have to design the language
> around the ability to enumerate references.
>

actually, it can be done, but mostly in the form of conservative GCs, 
such as Boehm.

I also use a GC, which is functionally similar to the Boehm GC as well, 
but differs mostly in the use of type-tagging (and some ability to 
assign special treatment to type-tags), so it is a little different.

I ended up primarily using it with a hybrid strategy, where manual 
memory-management is used for the most part, and GC is used mostly to 
clean up for the case of memory leaks.

[toc] | [prev] | [next] | [standalone]

#23488

BGB <cr88192@hotmail.com> writes:

> On 7/21/2012 4:32 AM, Nobody wrote:
>> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>>
>>> Hi Can anyone explain why C has added support for pthreads, while NOT
>>> adding support for garbage collection?
>>
>> GC requires a "walled garden", which C isn't.
>>
>> You can't just "add support" for GC, you have to design the language
>> around the ability to enumerate references.
>>
>
> actually, it can be done, but mostly in the form of conservative GCs,
> such as Boehm.

People are, I think, talking at cross purposes.  Those who say "it can
be done" mean it can be done in a way that works for some (possibly
large) set of programs.  Those that say it can't be done mean that there
are correct C program which will break when linked, unchanged, against a
collecting implementation of malloc.

The discussion would involve much less pointless back-and-forth if
everyone started out by agreeing that it can work for a lot of programs
but it can't work for all programs.  The debate could then be about the
kinds of program for which GC might or might not be useful.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23493

On 7/21/2012 11:38 AM, Ben Bacarisse wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/21/2012 4:32 AM, Nobody wrote:
>>> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>>>
>>>> Hi Can anyone explain why C has added support for pthreads, while NOT
>>>> adding support for garbage collection?
>>>
>>> GC requires a "walled garden", which C isn't.
>>>
>>> You can't just "add support" for GC, you have to design the language
>>> around the ability to enumerate references.
>>>
>>
>> actually, it can be done, but mostly in the form of conservative GCs,
>> such as Boehm.
>
> People are, I think, talking at cross purposes.  Those who say "it can
> be done" mean it can be done in a way that works for some (possibly
> large) set of programs.  Those that say it can't be done mean that there
> are correct C program which will break when linked, unchanged, against a
> collecting implementation of malloc.
>

and, I wasn't thinking about replacing "malloc()" in the first place, 
rather my GC works via its own calls ("gcalloc()", "gctalloc()", 
"gcmalloc()", "gcfree()", ...).

in this case, linking most C programs unchanged against the GC wouldn't 
change or break anything, but they wouldn't be using the GC in this case 
either...


> The discussion would involve much less pointless back-and-forth if
> everyone started out by agreeing that it can work for a lot of programs
> but it can't work for all programs.  The debate could then be about the
> kinds of program for which GC might or might not be useful.
>

or, possibly, what exact form the GC would take in the first place...

[toc] | [prev] | [next] | [standalone]

#23498

בתאריך יום שבת, 21 ביולי 2012 17:38:12 UTC+1, מאת Ben Bacarisse:
> BGB <cr88192@hotmail.com> writes:
> 
> People are, I think, talking at cross purposes.  Those who say 'it can
> be done' mean it can be done in a way that works for some (possibly
> large) set of programs.  Those that say it can't be done mean that there
> are correct C program which will break when linked, unchanged, against a
> collecting implementation of malloc.
> 
In C a pointer is valid if saved to a file in binary form then read back in again. It's invalid if read back in to an second instance of the program. So the standard needs a tweak to make the first situation also invalid.
I don't see that as a problem, except for very specialised memory paging software that lives deep down in the bowels of the operating system. That's generally written in a non-standard version of C anyway.
 

[toc] | [prev] | [next] | [standalone]

#23501

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> בתאריך יום שבת, 21 ביולי 2012 17:38:12 UTC+1, מאת Ben Bacarisse:
>> BGB &lt;cr88192@hotmail.com&gt; writes:
>> 
>> People are, I think, talking at cross purposes.  Those who say 'it can
>> be done' mean it can be done in a way that works for some (possibly
>> large) set of programs.  Those that say it can't be done mean that there
>> are correct C program which will break when linked, unchanged, against a
>> collecting implementation of malloc.
>> 
> In C a pointer is valid if saved to a file in binary form then read
> back in again. It's invalid if read back in to an second instance of
> the program. So the standard needs a tweak to make the first situation
> also invalid.

Why?  What would be the benefit?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23503

On Sat, 21 Jul 2012 20:13:28 +0100, Ben Bacarisse wrote:

>> In C a pointer is valid if saved to a file in binary form then read back
>> in again. It's invalid if read back in to an second instance of the
>> program. So the standard needs a tweak to make the first situation also
>> invalid.
> 
> Why?  What would be the benefit?

What would be the benefit in writing a pointer to a file, or to making
that invalid?

Writing a pointer to a file may be useful for virtual memory systems such
as that used by the Win16 API.

Forbidding writing pointers to files would eliminate one possible
mechanism whereby "transparent" GC would fail.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web