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

[Paul Hsieh]

Charlton Wilbur wrote: [...]

But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? 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.

And I did not wait for people in ANSI to build lcc-win.

So What?

So why do you insist on discussing lcc-win's non-ISO extensions here in
comp.lang.c?

I do not speak for Jacob Navia, but this is just utter nonsense. Do
you mean why does Jacob Navia not conform to the mindless consensus?
Why don't you guys make a charter and see if its gets some kind of
official stamp of approval by someone? Why don't you guys go and make
your own group and call it comp.lang.c.accordingtothestandardalone or
comp.lang.c.majorityrules? In short, go fly a kite.

(And why do you continue to refer to ANSI, the American National
Standards Institute, rather to ISO, the organization that issued the C
standard? I've asked you this before.)

Probably because he's not pedantic. You know sometimes I say Linux,
when I know I should be saying Gnu/Linux. But I have toe jam that
needs attending to.

Garbage collection breaks legal C programs. It can even break strictly
conforming C programs.

You mean if its *enabled* it breaks legal C programs. So do many of
the changes in C99. What's your point?

[...] Any program that stores a pointer value in a
place or format where the garbage collector can't recognize it as a
pointer will potentially be broken by GC.

Yes and programs that aliased pointers of two different types and
relied on compilers being conservative and not assuming they don't
overlap are potentially broken as well (by C99). Did you object as
loudly when that happened?

Perhaps such programs are rare, but you persist in ignoring them, even
when the issue is repeatedly pointed out to you.

I haven't followed JN's GC proposal too closely, but if he had a way
of turning it off (which I would highly recommend) then I don't see
the issue.

The Boehm GC library makes it abundantly clear that its practical,
possible, and desirable (for at least some applications) to have GC in
the C language. Perhaps the real question is, why are you fighting so
hard against it, instead of trying to find a good way of accommodating
it?

If GC were to be added to the language, the standard would have to
state that certain programs whose behavior is currently well defined
becomes undefined in the presence of GC.

That standard does have language that points this out today about each
successive iteration of the standard already. So what would be new?

I'm not stating an opinion on whether GC *should* be added to standard
C, just pointing out that it cannot be done with no changes at all to
the language.

If he continues to support free() then I don't understand why your
issue isn't instead just a demand for the ability (or perhaps default)
of being able to turn GC off.

 

[jacob navia]

I haven't followed JN's GC proposal too closely, but if he had a way
of turning it off (which I would highly recommend) then I don't see
the issue.

If you call malloc/free and do not call GC_malloc the GC is
completely turned off!

It is a library!

If you do not use it you do not use it and it will not
be linked with your program!

The GC in lcc-win is an OPTIONAL feature.

But even THAT is too much for the regulars

 

[Martin Ambuhl]

Because I have the right to do that according to the charter
of this group published when this group was created.

Jacob has been around long enough to know that this newsgroup predates
charters. His claim to have a right based on a non-existent charter
should tell you to ignore anything he writes. The reasons that
comp.lang.c has survived as one of the oldest and most successful
newsgroups include the fact that it preserves the concept of topicality.
That Jacob intends, and has proven repeatedly, that he intends to
destroy the concept of topicality in comp.lang.c means that his intent
is to destroy comp.lang.c. And he wonders why people have a problem
with him.

Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.

And, that, my friends, is Jacob as his best. It is clear that we do
discuss things at a "technical level", it is clear that the principal
poster of "polemic" is none other than Jacob. Those who are unclear
about his destructive role should heed this.

 

[Dik T. Winter]

> int main(void)
> {
> FILE *f = fopen("foo","w");
> disk_format("c:");
> fprintf(f,"not reached\n");
> fclose(f);
> }
>
> The function disk_format() breaks programs that were legal before...
> How bad!

I do not think the program will break. The worst that should happen is
that fprints returns a negative value and that fclose returns EOF.

 

[Kenny McCormack]

Kenny McCormack wrote:
[...]

Think of this ng as like a church. Church people have very rigid
(generally 13th century [*]) views on things. They ain't gonna change.

[*] If you're lucky. 13th century for Christians. 8th century for,
e.g., Muslims.

Good thing I'm Jewish -- we have 58th century ideas!

Good point!

 

[Keith Thompson]

Charlton Wilbur wrote: [...]
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? 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.

And I did not wait for people in ANSI to build lcc-win.

So What?

So why do you insist on discussing lcc-win's non-ISO extensions here
in comp.lang.c?

Because I have the right to do that according to the charter
of this group published when this group was created.

How many times must we explain to you that this newsgroup has no charter?

Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.

Not at all. I discuss technical issues here all the time.
Specifically, I discuss technical issues related to standard C, which is
the topic of this newsgroup. (Please don't try to claim that comp.std.c
is for discussing standard C and comp.lang.c is for non-standard C;
we've been over that.)

int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached\n");
fclose(f);
}

The function disk_format() breaks programs that were legal before...
How bad!

Be serious. Obviously disk_format(), or any non-standard function, is
going to do whatever it does.

You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather than
addressing it.

If I'm mistaken, refute what I said.

 

[Keith Thompson]

I do not think the program will break. The worst that should happen is
that fprints returns a negative value and that fclose returns EOF.

Depends on the implementation. Formatting a disk may or may not
interfere with a running program; the standard doesn't say.

It's at least conceivable that the object code for fprintf() is loaded
on demand when it's first called. It's also possible, and I suspect
more likely, that it will behave as you say.

 

[Keith Thompson]

Charlton Wilbur wrote: [...]
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? 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.
And I did not wait for people in ANSI to build lcc-win.
So What?

So why do you insist on discussing lcc-win's non-ISO extensions here in
comp.lang.c?

[...] In short, go fly a kite.

Go fly your own damned kite.

Probably because he's not pedantic. You know sometimes I say Linux,
when I know I should be saying Gnu/Linux. But I have toe jam that
needs attending to.

Toe jam. Now there's a good argument.

You mean if its *enabled* it breaks legal C programs. So do many of
the changes in C99. What's your point?

My point is simply that the point should be acknowledged.

[...] Any program that stores a pointer value in a
place or format where the garbage collector can't recognize it as a
pointer will potentially be broken by GC.

Yes and programs that aliased pointers of two different types and
relied on compilers being conservative and not assuming they don't
overlap are potentially broken as well (by C99). Did you object as
loudly when that happened?

No, I didn't. I'm aware that C99 included some changes that broke
existing C programs. I'm not sure that the particular issue you mention
is a change from C90 to C99, but you could well be correct, and I'll
accept it for the sake of argument.

The C99 standard explicitly acknowledges cases where old code can be
broken. (It may not do so perfectly in 100% of the cases, but certainly
the attempt is made.)

[...]

 

[Keith Thompson]

If you call malloc/free and do not call GC_malloc the GC is
completely turned off!

It is a library!

If you do not use it you do not use it and it will not
be linked with your program!

Then perhaps my objection (which was a *minor* one) was in error. If it
doesn't affect existing code (which doesn't call GC-malloc),
specifically if it doesn't "alter the behavior of any strictly
conforming program" (C99 4p6), and as long as GC_malloc and any other
new functions are declared in a new header, then it would seem to be a
permitted extension.

Any documentation for this extension, or the section describing it in a
new C standard if it were added, would certainly need to mention that
certain constructs invoke undefined behaviors -- but such constructs
can't occur in a portable C99 program.

But of course you couldn't have just replied to my *technical* point
with a *technical* response.

[...]

 

[Keith Thompson]

Paul Hsieh wrote:
[...]

> So take for example some of the things I am proposing: 1) Heap
extensions and heap debugging APIs. These things obviously exist in
various products and compiler extensions -- no two of which are
compatible, of course. 2) "mulhi" and "SIMD" instructions -- many
modern compiler come with assembly language extensions, and that's how
they are implemented; one by one, every one of them incompatible with
the next (actually Intel is somewhat compatible with MSVC, but that's
a weird special case.) 3) Some kind of fseek/ftell on intmax_t
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".

People clearly want and need those things. The way it happens today
is kind of pathetic. Why do I have to learn a different way to deal
with those things as a Solaris, or a VxWorks or a QNX or even a Linux
programmer?

If you want to advocate changes to the C language, I encourage you to do
so in comp.std.c. The vast majority of us here in comp.lang.c are
users, not implementers or committee members; even if we like your
ideas, we're in no position to do anything about them.

 

[Richard Heathfield]

Keith Thompson said:

<lots of good points that I'm not going to argue about, either way, because
of a (conditional) promise I made a day or two ago, although I see little
sign that the other side of the bargain is being kept, so I won't consider
that promise to be binding for very long unless I see some serious action
here...>

(And why do you continue to refer to ANSI, the American National
Standards Institute, rather to ISO, the organization that issued the C
standard? I've asked you this before.)

ANSI issued the first "official" C Standard, in 1989. Lots and lots of
people had been talking about the ANSI Standard with eager anticipation.
One of my K&R2s has the legend "Based on Draft-Proposed ANSI C" emblazoned
on a cover flash. When I first started learning C (in 1989, by the way),
it was ANSI C that the course tutors - using a certain amount of artistic
licence - claimed to be teaching me. Those compiler implementors who could
keep up with the standardisation process leapt at the chance to be able to
provide an early release of "ANSI C". The expression "ANSI C" has embedded
itself firmly in the minds of the C programming community.

Furthermore, the ISO standardisation of 1990 was little more than a
rubber-stamping exercise. I think ISO's only contribution was to muddle up
the section numbers. In a C context, ANSI and ISO are practically
synonyms.

To criticise C programmers for referring to ANSI C is, I think,
unnecessary. It took me years to retrain from ANSI C to ISO C (not the
languages, of course, which are identical - just the names). Some people
haven't completed that retraining process yet. And some never will. Er, so
what? We all know what they mean, right?

 

[jacob navia]

jacob navia wrote:
Charlton Wilbur wrote:
[...]
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? 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.

And I did not wait for people in ANSI to build lcc-win.

So What?

So why do you insist on discussing lcc-win's non-ISO extensions here
in comp.lang.c?

Because I have the right to do that according to the charter
of this group published when this group was created.

How many times must we explain to you that this newsgroup has no charter?

Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.

Not at all. I discuss technical issues here all the time. Specifically,
I discuss technical issues related to standard C, which is the topic of
this newsgroup. (Please don't try to claim that comp.std.c is for
discussing standard C and comp.lang.c is for non-standard C; we've been
over that.)

int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached\n");
fclose(f);
}

The function disk_format() breaks programs that were legal before...
How bad!

Be serious. Obviously disk_format(), or any non-standard function, is
going to do whatever it does.

You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather than
addressing it.

If I'm mistaken, refute what I said.

If you allocate memory with GC_malloc, then store the pointer in a disk
file or hide it from the GC it will invoke UB. If you instead of using
GC_malloc you use malloc (that is still available and free for you to
use) NOTHING will happen since the GC only frees memory allocated with
GC_malloc. Programs that used malloc will CONTINUE to run as before,
the GC is backwards compatible with existing code.

I have repeated this OVER and OVER and here it goes yet one more time.

 

[Boudewijn Dijkstra]

Op Thu, 15 Nov 2007 20:23:21 +0100 schreef Chris Thomasson

Fair enough. Humm... Can you use Java to create a brand new GC
implementation for itself, thus totally replacing the one in the VM?

It wouldn't be very handy for a VM that doesn't run mostly on Java
already, because you'd need all the necessary information needed for GC,
accessible in the Java layer. Note that there is actually a JVM that does
run mostly on Java, though I don't remember its name or how GC is done.

 

[Keith Thompson]

Keith Thompson wrote: [...]

You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather
than addressing it.

If I'm mistaken, refute what I said.

If you allocate memory with GC_malloc, then store the pointer in a disk
file or hide it from the GC it will invoke UB. If you instead of using
GC_malloc you use malloc (that is still available and free for you to
use) NOTHING will happen since the GC only frees memory allocated with
GC_malloc. Programs that used malloc will CONTINUE to run as before,
the GC is backwards compatible with existing code.

I have repeated this OVER and OVER and here it goes yet one more time.

There, that wasn't so difficult, was it?

I know I've raised this point before. I don't recall you ever addressing it,
other than just asserting that GC requires no changes to the core language. If
you did, I've forgotten. (Perhaps you could provide a pointer to a earlier
response in which you actually addressed the point?)

So it appears that I was mistaken. The point I was missing (or had forgotten,
whatever) is that GC only affects memory allocated by GC_malloc(). Even if GC
is enabled, a block of memory allocated by malloc() will never be garbage-collected.

 

[Charlton Wilbur]

>> [...] 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!

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.

If your library is useful, people will use it regardless of whether
ANSI or ISO bless it. 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.

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? Or is your hope that ANSI or ISO
standardization will somehow magically cause all this to happen?

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.

One of the reasons ANSI achieved what it did was by focusing on the
common core subset. 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.

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.

Charlton

 

[Richard Heathfield]

Keith Thompson said:

So it appears that I was mistaken. The point I was missing (or had
forgotten,
whatever) is that GC only affects memory allocated by GC_malloc(). Even
if GC is enabled, a block of memory allocated by malloc() will never be
garbage-collected.

That kinda defeats the point of AGC, since it means that you can't use a
third-party library with the same devil-may-care attitude to GC that an
AGC would invoke in your own code. You have to read the lib docs to find
out how to manage the memory. (Personally I don't see this as a trial, but
it's clearly a weakness in the argument for AGC.)

 

[jacob navia]

Keith Thompson said:



That kinda defeats the point of AGC, since it means that you can't use a
third-party library with the same devil-may-care attitude to GC that an
AGC would invoke in your own code.

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

You have to read the lib docs to find
out how to manage the memory. (Personally I don't see this as a trial, but
it's clearly a weakness in the argument for AGC.)

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!

 

[Richard Heathfield]

jacob navia said:

I have a parse error with the above sentence.

Charlie Gordon has agreed to post corrections to all your mistakes, to save
me the trouble. So far he hasn't done so, but we must be patient; I am
sure he will eventually post corrections to the mistakes you have made in
this article too.

 

[ymuntyan]

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!

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

Best regards,
Yevgen

 

[jacob navia]

jacob navia said:


Charlie Gordon has agreed to post corrections to all your mistakes,

My errors maybe, but not yours.



I mean can you explain what is AGC your honour?

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