"Criticism of the C programming language ??????"

[Richard Heathfield]

(e-mail address removed) said:

It's called "strawman" I believe. Jacob Navia + GC => sloppy
programming and GC
is a magic wand or nothing. Come on, Richard Heathfield must have said
something,
he said something (hopefully I didn't call him a liar here somehow).

Well, of course I *did* say something, which I know Keith will be able to
understand, as will many other people here, although of course not
everyone. Nor do I believe I was setting up a strawman, particularly. I
certainly did not claim that AGC must either be a magic wand or nothing.
My claim was merely that a proposed AGC system that does not work for
third party libraries is significantly weaker than one that does. (Nor
would one need a magic wand to achieve such an AGC.)

 

[ymuntyan]

(e-mail address removed) said:



Well, of course I *did* say something,

I commented rather on *why* you did. Or rather my comment was made
because
of what I think about why you did. I bet everybody around (except
Keith, I think,
he's not able to catch RH-JN conversations in his permanent pedantry
mode)
understands why.

which I know Keith will be able to
understand, as will many other people here, although of course not
everyone.
Nor do I believe I was setting up a strawman, particularly. I
certainly did not claim that AGC must either be a magic wand or nothing.
My claim was merely that a proposed AGC system that does not work for
third party libraries is significantly weaker than one that does.

Yep. Merely said this and this.

Best regards,
Yevgen "I swear I will read comp.lang.c++ instead" Muntyan

 

[Richard Heathfield]

jacob navia said:

I mean can you explain what is AGC

I simply meant Automated Garbage Collection.

your honour?

An attempt at sarcasm, perhaps?

Or why you suppose that if I use the gc, library xyz.lib
automagically uses it too?

In my experience, explaining things to you is a complete and utter waste of
time, since you appear to be incapable of holding a rational debate,
preferring to insult your opponents rather than try to understand them.
You owe many apologies to many people in this group. I doubt very much
whether those apologies will ever be forthcoming, of course.

Because of your debating style, which seeks to attack that which it does
not understand, I have long since stopped trying to educate you, and have
contented myself with correcting your mistakes. Even THAT was happening so
often that it looked like I was attacking you out of some kind of
vendetta, so I stopped, and for a while your mistakes went largely
uncorrected.

Then I corrected a few, and again people thought I was attacking you. So
Charlie Gordon (one such person) agreed to my proposal that *he* should
correct all your mistakes in return for a promise that I would not mention
your name ever again. But he shows no sign of keeping his end of the
bargain, so we're back to square one again.

No doubt there are those who will see *this* reply as an attack. But in
fact it is merely an explanation, addressed more to the group than to you
(since I see no value in explaining things to you), of why I am not
answering your question.

Bottom line: if you want to learn stuff from me or from anyone else here,
leave your arrogance at the door, apologise to all those you have called
liars, fools, polemicists, etc etc etc ad nauseam, and learn how to take
part in a debate without assuming that anyone disagreeing with you must be
wrong, or trying to mock them simply because you don't understand them.

 

[Richard Heathfield]

(e-mail address removed) said:

I commented rather on *why* you did. Or rather my comment was made
because of what I think about why you did.

My reply was mostly addressed to Keith, and I was making a valid technical
point. If you think it's part of some kind of vendetta, well, you're
wrong. I'm not interested in vendettas, vendettae, or vendetti. I'm just
weary of explaining the blindingly obvious to the obviously blind. Keith
is perfectly capable of understanding the technical point I was making,
and I'm sure you are too, if you'll only cut through your own
preconceptions and look at what I actually wrote.

 

[jacob navia]

jacob navia said:



I simply meant Automated Garbage Collection.

Ahh , so I guessed correctly. Thanks[snip long blah blah about why I am bad and the evil of my ways]
Bottom line:

You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.

People here say that the GC will make running programs
go awry because of if they do some legal hacks they
would not run any more. That was K. Thomson argument.

When told that the GC is backwards compatible with
existing code, you start arguing that this fact
makes it less useful since third party libraries
will still need their specific memory management calls.

Either way I am wrong. If the GC would take over
malloc and friends that would make current code
break down sometimes, and if it doesn't then it is
less useful.

Head I win, tails you loose.

 

[Richard Heathfield]

jacob navia said:

You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.

Correct, I haven't; that's because, judging by past experience, I see no
value in attempting to educate you. If you had understood my previous
reply, you would have realised this.

 

[Default User]

jacob navia said:

I really wish you hadn't opened your killfile for that topicality
thread. You've reverted to the old way of incessant and repetitious
arguing with Jacob, to no beneficial effect.




Brian

 

[Paul Hsieh]

[...] We've seen, in the case of things like C99, that the
imprimatur is insufficient to get people to use the thing, and
we've seen, in the case of things like BSD sockets, that
usefulness does not require official imprimatur to proliferate.

PH> So there's no "standard sockets" that anyone can assume -- its
PH> just a platform specific idea.

Of course! Not all systems have sockets. Not all systems use TCP/IP.
ANSI and ISO are in no position to mandate that they do, or should!

I don't have a specific proposal about sockets. I was just using it
as an example of the problem of the compiler specific fragmentation
that we see today. But having more generalized stream IO would go a
long way to solving the problem.

PH> My proposals tend to be limited to the library. Perhaps you
PH> can enlighten me with examples where my proposals would lead
PH> to actually giving something up (to be a trade off you have to
PH> gain something in balance with giving something up)? When
PH> people try to challenge me on this, the best I get is the
PH> typical circular reasoning: "that's not in the standard,
PH> therefore its not portable" or some crap like that, when
PH> clearly I am trying to suggest something to be standardized.

I haven't given you that; I've asked, three times now, why you think
your library needs the ANSI/ISO imprimatur. You've just given me
bafflegab.

What the hell are you talking about? I have given very precise, and
so far unchallenged reasons for each of my proposals. They either
expose ubiquitous (or easily emulated) existing platform capabilities,
more closely match platform functionality or help solve a very common
problem with the C language.

If your library is useful, people will use it regardless of whether
ANSI or ISO bless it.

*Libraries* (plural). This has turned out to be the case with the
Better String Library, a hash function I have made, and pstdint.h, as
far as recent examples go. I don't know how much of my old public
code is being used out there. In the specific case of the Better
String Library, one of its features requires that the source be
available (which is contrary to what ANSI has done with C so far) and
I didn't really want the ANSI C committee touching it to be honest.

As to other libraries, such as >= 64 bit file I/O, this isn't *my*
library. Its just something that is a logical extension of what has
been implemented in numerous C compilers already.

As to improved heaps, as you might well imagine, mine is *VERY* non-
portable, and may be too slow for some benchmarks (its slower at
malloc/free speed, but its generally faster on realloc speed, and
tends to give less fragmented results than other heaps I have tested
-- so it will tend to win more *real world* benchmarks as opposed to
direct API test benchmarks.) I am also entertaining the idea of
selling it, since fixing poor C platforms seems to be a real business
opportunity.

Since I am very comfortable with assembly language, it doesn't phase
me much to code up mulhi's or bitcount or bitscan by myself. I just
know that this is not really sustainable in code that's more
widespread.

[...] If your library is not useful, people won't
even bother to implement it, regardless of whether ANSI or ISO bless
it. There's evidence for both of these.

No ... people avoided C99's library, because it came with language
changes to C99 which were either unimplementable or required major
rewrites of the compiler. When they are just changes to the library
which are isolated and straightforward, compiler vendors which are
maintaining their compilers will generally adopt them.

PH> So who says I have not? The problem is that my various
PH> efforts are in pieces, not well documented, sporadically
PH> tested, very context dependent, not portable, not peer
PH> reviewed, etc (the main exception of this being Bstrlib which,
PH> by now, is at compiler-level quality). And I know there are
PH> thousands of different developers who have written
PH> substantially the same thing with different degrees of quality
PH> (probably at least some are better).

So you want ANSI and ISO to standardize something that's in pieces,
not well documented, sporadically tested, very context dependent, not
portable, and not peer reviewed?

So many straw men, so little time huh? What I've implemented and what
I am proposing are two different things. Compiler vendors don't
automatically get free access to my code regardless of whether or not
that would be a good idea.

[...] Or is your hope that ANSI or ISO
standardization will somehow magically cause all this to happen?

That is the entire point of standardization. They are implemented in
the compiler which is a critical tool -- so clearly the code would
have to go through that kind of a process.

PH> ANSI accomplished one thing -- and they did it back in 1989.
PH> They got all the compiler vendors to agree to a common
PH> standard. This meant that people could write common code. It
PH> meant that people did not duplicate effort in redesigning and
PH> reimplementing common things like FILE IO, some math, etc. If
PH> you don't see the value of this, then this discussion is over.

I see the value of it. I don't see the value in standardizing every
other library you think someone, somewhere might find useful.

Oh you must be right. Debugging memory corruption problems must be
such a marginal problem that nobody has run into. Geez louise. And
high performance encryption? I suppose nobody bothers to do that in C
code, otherwise you would see user accounts and passwords on *ALL*
major operating systems shipping today. And its a good thing that
nobody ever tries to randomly access a large single file on a
rewritable DVD, since there's never a good reason to have a > 4GB
file, apparently (and we can safely ignore supercomputer applications
that write really large output, since simulating the climate, and
nuclear seems to be an issue that nobody cares about anymore).

Someone somewhere indeed. These are problems *already solved*, by
*WORKING AROUND* the limitations of the standard and going to non-
portable solutions.

One of the reasons ANSI achieved what it did was by focusing on the
common core subset.

That made sense in 1989 because pr. In 1999? They now are the object
of shunning at best, but more appropriately deserving of ridicule and
disappointment.

[...] As soon as you start adding networking libraries
or graphics libraries or threading libraries, you're imposing
requirements on that common core subset that are not applicable to all
or even most platforms.

We need to get a photograph of you for the wikipedia entry on straw
man.

Obviously, you wont challenge me on what I've actually said or the
positions I represent.

So in the real world that I live in, this is accomplished by keeping
ANSI/ISO C as the standard for the language, and using additional
libraries that are standard but not necessarily universal. I'm trying
to figure out why this is not an acceptable solution for you.

Its fine for me! In fact I would love it if we all still programmed
assembly code! Great for my job security! On this gross and twisted
nightmare of non-portable nonsense that we all engage in, I am
something of a specialist. That's obviously not the point. There is
a "computer scientist" in me that says that we would all be a hell of
a lot more productive if we were programming on the same page and
could make the same assumptions. I want to solve *new* problems, not
old ones that are obvious and uninteresting.

 

[Richard Heathfield]

Default User said:

You've reverted to the old way of incessant and repetitious
arguing with Jacob, to no beneficial effect.

No, I haven't.

I suggest you direct any complaints to him, since he's the one that posts
all the twaddle.

 

[Keith Thompson]

jacob navia said:



I simply meant Automated Garbage Collection.

Ahh , so I guessed correctly. Thanks[snip long blah blah about why I am bad and the evil of my ways]
Bottom line:

You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.

People here say that the GC will make running programs
go awry because of if they do some legal hacks they
would not run any more. That was K. Thomson argument.

When told that the GC is backwards compatible with
existing code, you start arguing that this fact
makes it less useful since third party libraries
will still need their specific memory management calls.

Either way I am wrong. If the GC would take over
malloc and friends that would make current code
break down sometimes, and if it doesn't then it is
less useful.

Head I win, tails you loose.

There is no free lunch. There are always tradeoffs. The fact that you
take this fact as a personal affront is not my problem.

There is no way to add GC to the language, or even to an implementation,
without *some* cost. If it takes over malloc and friends, the cost is
that some (perhaps obscure) code could break, the pattern of memory
usage would change, and there might be performance problems (the latter
can be particularly problematic for real-time code). If not, if instead
only memory allocated by GC_malloc is garbage-collected, then you've got
two memory allocation/deallocation systems, potentially both operating
in the same program at the same time. For any given pointer, you have
to keep track of whether it was allocated by malloc (and therefore must
be freed explicitly) or by GC_alloc (and therefore must not be freed
explicitly).

I do not argue that *either* of these is necessarily a reason to exclude
GC from an implementation, or even from the language. I merely point
out some technical issues. (You wanted to discuss technical issues, right?)

Earlier, I incorrectly assumed that GC would potentially break existing
programs that don't use it explicitly. Let me explain why I made that
assumption.

Consider a hypothetical GC implementation (not the one you're proposing)
in which memory allocated by malloc can be garbage-collected, and free
becomes a no-op (or perhaps forces an immediate deallocation). Then
existing programs and libraries gain the benefits of GC (in some cases,
memory leaks just go away), and new code can be written more simply
without bothering to call free().

Presumably there's a way to enable or disable GC for each program,
perhaps by specifying a library at link time.

For some applications, it seems to me that this could potentially be a
good thing. Most programs, I suspect, would continue to work in such an
environment, some better than they did before. Those few programs
that play games with pointers would just have to be built with GC
disabled, or modified to keep the pointers visible.

Given such an implementation, it would be very important to specify that
certain actions which are well-defined in standard C would become undefined.

In my earlier comments, I failed to distinguish between these two
alternatives, and I thought that you were ignoring a very important
issue, though one that perhaps affects only a few programs.

Now, a few questions about the form of GC that you propose.

If you allocate memory with GC_alloc, and free the same memory with
free, what happens? Is it undefined behavior?

Is there a GC_free function that forces an immediate deallocation?

Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory. Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers? Or, since the malloc()ed memory is still in the program's
address space, will this create a leak? Has the interaction between GC
and the existing malloc/free interface been thought through?

To be very clear, none of this implies that I'm rejecting your ideas.
I'm merely asking some technical questions.

 

[jacob navia]

Keith Thompson wrote:

[snip]

Consider a hypothetical GC implementation (not the one you're proposing)
in which memory allocated by malloc can be garbage-collected, and free
becomes a no-op (or perhaps forces an immediate deallocation). Then
existing programs and libraries gain the benefits of GC (in some cases,
memory leaks just go away), and new code can be written more simply
without bothering to call free().

This can't be done with a recompile.

Presumably there's a way to enable or disable GC for each program,
perhaps by specifying a library at link time.

You can disable the GC from a GC enabled program by defining
void *GC_malloc(size_t s)
{
return malloc(s);
}

But obviously, nothing can be done for the missing fre()
calls!

For some applications, it seems to me that this could potentially be a
good thing. Most programs, I suspect, would continue to work in such an
environment, some better than they did before. Those few programs that
play games with pointers would just have to be built with GC disabled,
or modified to keep the pointers visible.

Given such an implementation, it would be very important to specify that
certain actions which are well-defined in standard C would become
undefined.

In my earlier comments, I failed to distinguish between these two
alternatives, and I thought that you were ignoring a very important
issue, though one that perhaps affects only a few programs.

Now, a few questions about the form of GC that you propose.

If you allocate memory with GC_alloc, and free the same memory with
free, what happens? Is it undefined behavior?

YES!
You can't do that because the pointer is not in the malloc
list of allocated memory. It will have the same effect of
calling free with a pointer that wasn't allocated at all!

Is there a GC_free function that forces an immediate deallocation?

Yes.

Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory.

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers?
No.

Or, since the malloc()ed memory is still in the program's
address space, will this create a leak?
Yes.

Has the interaction between GC
and the existing malloc/free interface been thought through?

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

If you have GC pointers in a malloced structure you should set that
structure to zero (or other value) to avoid that the GC sees the
pointer and thinks that memory is used.

To be very clear, none of this implies that I'm rejecting your ideas.
I'm merely asking some technical questions.

In general, mixing two systems of memory allocation is not a good idea.
The best is to replace malloc/free by GC_malloc and be done with it,
if you want to use the GC, and to avoid the GC when you want to use
malloc.

The malloc/free system has its uses, and can be reasonable choice in
small applications or in applications where the GC would be impractical
for whatever reasons.

 

[jacob navia]

Keith Thompson wrote:

[snip]

Consider a hypothetical GC implementation (not the one you're
proposing) in which memory allocated by malloc can be
garbage-collected, and free becomes a no-op (or perhaps forces an
immediate deallocation). Then existing programs and libraries gain
the benefits of GC (in some cases, memory leaks just go away), and new
code can be written more simply without bothering to call free().

This can't be done with a recompile.

ERROR

That should have been

This can't be done without a recompile
*******

Excuse me for that.

 

[Francine.Neary]

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

What if the reference to your pointer is stored in memory that has
been malloc()ated by a third-party library, which doesn't zero its
allocated memory before free()ing it?

 

[jacob navia]

What if the reference to your pointer is stored in memory that has
been malloc()ated by a third-party library, which doesn't zero its
allocated memory before free()ing it?

Easy. You should set that field to zero before you
pass it to the library function to be freed.

Normally, a library will want to free the object it allocated, and
has an API for it, say

void FreeFoo(FOO *foo);

Suppose that foo->ptr contains your GC pointer. Before calling
FreeFoo() you write:
foo->ptr = NULL;

But if the library NEEDS foo->ptr and would crash if foo->ptr
is NULL, you have a memory leak. Do not use the GC to allocate
foo->ptr. Use the function that the library documentation uses.
If it uses malloc use malloc too.

It is very rare that a library imposes such restrictions. In most
cases setting foo->ptr to NULL before passing it to the library
to be destroyed is enough.

 

[Paul Hsieh]

[...] Now, a few questions about the form of GC that you propose.

If you allocate memory with GC_alloc, and free the same memory with
free, what happens? Is it undefined behavior?

Personally I would recommend that free detect the kind of memory it
was about to free and call GC_free() (as you propose below) in its
place if its GC-memory. So from a lazy programmer's point of view, GC
memory just seems to be safer heap-like memory (however, there is also
a performance cost.)

Is there a GC_free function that forces an immediate deallocation?

Perhaps, but it would not work the way you are thinking. GC only
makes sense from a performance point of view when you amortize the
cost. I.e., GC cycles have to do all or nothing, and they have a non-
trivial minimum cost (you have to walk over all of static memory, for
example.)

But what you could do, is put the allocation into a size-range
partitioned free-list. So the next time you did a GC_malloc, you
would first search through this free-list for allocations instead of
the GC_heap. This unfortunately, returns us to the *problems* of
strict alloc/free managed memory (i.e., you can GC_free a pointer
which still has live references to it.) However, what I was suggest
is that we throw our hands up and just say, "well, this is the penalty
for using C -- failure to code correctly may lead to corruption". So
during GC time, you would categorize each GC_allocation as being
either pointed to by a regular live program reference, or the free-
list (it may also be pointed to by other things, but GC_free() would
imply that those are references that are not really used) or by
nothing. Allocations in the free-list would first need to be removed
from the free-list, then recycled in the same way that other old
allocations that had nothing pointing to them.

Personally, I think it would be very important to have this kind of
implementation, as it would give programmers a reasonable way to write
code which was somewhat "in between" strict alloc/free and GCed memory
by mixing and matching. Allocations that came out of a free list
would be presumably be much faster than a true GC allocation, and it
could serve as a quick fix for "false reference" scenarios (where
memory was not freed because a pointer pattern still points to it,
even though the reference is implicitly no longer used.)

Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory. Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers? Or, since the malloc()ed memory is still in the program's
address space, will this create a leak? Has the interaction between GC
and the existing malloc/free interface been thought through?

The way that "mark and sweep" works is that it walks through any
memory that is potentially reachable through program references. This
includes, stack, statics, and in this case it would have to the part
of the standard heap which has not been freed. So the question is, is
it possible to walk the heap memory that is currently allocated in an
efficient way? With one of my own heap designs, its certainly
possible to do this -- one can walk though OS-blocks one at a time,
and walk through the free memory in *address order*; which is enough
information for you to figure out the allocated areas.

 

[Francine.Neary]

Easy. You should set that field to zero before you
pass it to the library function to be freed.

Normally, a library will want to free the object it allocated, and
has an API for it, say

void FreeFoo(FOO *foo);

Suppose that foo->ptr contains your GC pointer. Before calling
FreeFoo() you write:
foo->ptr = NULL;

But if the library NEEDS foo->ptr and would crash if foo->ptr
is NULL, you have a memory leak. Do not use the GC to allocate
foo->ptr. Use the function that the library documentation uses.
If it uses malloc use malloc too.

It is very rare that a library imposes such restrictions. In most
cases setting foo->ptr to NULL before passing it to the library
to be destroyed is enough.

But it might be more complicated that that - you might need to know
more about how the library is implemented internally to avoid a memory
leak.

Suppose the library has an API like this:
void foo_init(void);
int foo_calc(struct bar *obj);
void foo_cleanup(void);

foo_calc performs some lengthy computation on obj. The library writer
decides to cache the previous few calculations, so foo_init sets up a
little table, and then foo_calc stores values of obj (to allow a
shallow comparison) and the important fields of *obj (to allow a deep
comparison if the shallow comparison succeeds), as well as the value
of the computation of course. Meanwhile, foo_cleanup free()s the table
without zeroing it.

If you pass a pointer to a GC_alloc()ed struct bar to foo_calc, won't
the problem Keith described occur?

 

[Malcolm McLean]

instead of long: every modern compiler I know implements some sort 64
bit fseek and ftell (again, each incompatible with the other), because
"64 bits ought to be enough for everyone".

I've still got some "give me 64" T-shirts left. These tasteful designs
feature the numerals "64" made up of 64 separate squares, and promote the
campaign for 64 bit ints.

I trust you'll be placing an order?

 

[Ben Bacarisse]

Keith Thompson wrote:

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

You were suggesting that GC is essentially a library issue and that
there is no change to the "core" language, but these two examples
suggest that a subtle change is required (or at least implied): for
GC to work well, every pointer must behave rather as if it were
volatile. In fact, all memory will have to be treated like that.

In "old C", a compiler can remove the memset in the sequence:

memset(ptr, 0, size_of_date);
free(ptr);

but in your C, that would be a mistake (well, sub-optimal, maybe).
Similar things apply to the 'ptr = NULL;' example. Are you proposing
to make this change to C's "as if" rules?

[BTW, is the GC you ship the Boehm one or your own?]

 

[J. J. Farrell]

I have a parse error with the above sentence. Maybe because I do not see
what is an AGC. Is it "A garbage Collector" ?

Let's suppose that. Then, I still do not understand that when you are
using the GC in YOUR application you expect somehow that automagically
other applications and third party libraries will use it too?

That would be strange from Heathfield, that otherwise never does
such huge assumptions...


Of course you have to read the docs before using a third party
library. And you use it as documented. If the library allocates
memory and expects the user should free it you do so. And you
would have to do that GC or not GC!

I fail to understand how someone that knows how programming works
expects that the GC will soleve magically all memory allocation problems
using unspecified third party libraries!

This sub-thread started with KT saying that garbage collection requires
semantic changes to the language. I've not thought about it in detail,
but it seemed likely to me that that was true. You responded by saying
that "garbage collection is just a library". I didn't see how that could
be true since, like KT, I was thinking of garbage collection integrated
into the language itself. In a later message, after a burst of silly and
pointless sarcasm, you were persuaded to explain that you were talking
about an additional memory allocation library which would support
garbage collection for memory it controlled.

This is very different from garbage collection as part of C itself, but
might certainly be useful to people who like garbage collection. Its not
being an integral part of C has the advantage that it doesn't introduce
backward compatibility issues and could be added fairly painlessly;
however, it has the disadvantage that it doesn't apply to all memory
allocations, and if the memory has been allocated by a third-party
library it is not immediately obvious whether or not that memory will be
garbage collected. Having two different types of allocated memory makes
things more complicated, and puts more requirements on the specification
of libraries.

If garbage collection were 'added to C' the programmer would expect that
all dynamically allocated memory would be garbage collected. Your
proposal doesn't do that, which is a disadvantage. RH was pointing out
that disadvantage; that's all. Most proposals have advantages and
disadvantages. Compared to adding garbage collection to C itself, your
proposal has the big advantage that it doesn't introduce backward
compatibility issues, but at the cost that the programmer can't simply
assume that garbage collection applies to all dynamically allocated memory.

Whether or not your proposal ever becomes part of the C definition
depends on how many people want garbage collection in C enough to make a
fuss about it, and how many of those would think your approach a good
way to do it. For those who don't care about garbage collection, I can't
immediately see much objection to the proposal, other than its making
the library definition bigger, and potentially requiring people to work
with garbage collection in the future if other libraries make use of it.

 

[J. J. Farrell]

[...] We've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.

...

If the standard endorses good ideas, *LOTS* of people will pick them
up. One of the things you are missing with BSD sockets, is the fact
that Microsoft went and implemented them with an interface that is
very different under Windows than it is under the Unixes (I wonder how
they implemented it under MacOS9). And various embedded systems don't
even bother with any kind of sockets. So there's no "standard
sockets" that anyone can assume -- its just a platform specific idea.
The capability of sockets is good -- the current state of
fragmentation is not so good. With effort you can reasonably write
wrappers that let you write socket code that is portable -- but
there's not single centralized standard for this.

<OT>FWIW things are slowly getting better with sockets since they are
now defined by POSIX. I expect it to be a while before Microsoft
conforms, though.</OT>