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

[user923005]

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

There are other problems with GC, when you have performance critical
operations.

If you are running a program and someone has used gc in a lib you are
using, then your program could 'hang' at inappropriate times when the
garbage collector is running.

It's a bigger problem than it sounds like. Although it is supposed to
be a bad idea, I find myself manually running the garbage collector in
GC languages to prevent inappropriate behavior (such as huge memory
consumption, very long pauses, etc.).

 

[Keith Thompson]

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

No problem.

But why can't it be done without recompiling? What am I missing?

Provide two libraries, one that provides the usual non-GC malloc() and
free() functions, and another that provides GC versions of them
(malloc() allocates space that can be garbage-collected, and free() does
nothing). Take an existing program that uses malloc and free, linking
it with the first library. Re-link the same program (no recompilation,
just relinking) with the second library, and if it doesn't do funny
stuff with pointers, the program still works but with automatic garbage
collection (and free() calls ignored).

Of course this won't work if you want to distinguish between malloc()
and GC_alloc(), but I explicitly assumed an implementation in which
there's no such distinction.

 

[William Pursell]

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

Maybe I'm missing something, but on my system it
certainly can:

$ ldd /bin/ls | grep libc
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc1000)

Update libc.so.6 and you get a new malloc.

 

[CJ]

Maybe I'm missing something, but on my system it
certainly can:

$ ldd /bin/ls | grep libc
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc1000)

Update libc.so.6 and you get a new malloc.

I believe that on MS-DOS, and presumably therefore on most versions of
Windows too, it isn't possibly to link libraries dynamically.

 

[Richard Heathfield]

CJ said:

I believe that on MS-DOS, and presumably therefore on most versions of
Windows too, it isn't possibly to link libraries dynamically.

MS-DOS had overlays, which were a way to load external code at runtime, so
they fulfilled much the same job as dynamically linked libraries.

As for Windows, one might reasonably describe it as little more than a
collection of dynamic link libraries. In most versions of Windows (and
probably all), it *is* possible to link libraries dynamically.

 

[Chris Hills]

Ironically, the argument you make in what follows applies equally well
to C99 itself. In other words your argument is essentially moving
*backwards* in time, referring to things for which we already have
precedent. Compare this to my position in which I have observed the
ANSI C committee approve radical changes to the language (i.e., C99)
so I know that are *willing* to change the language and I am well
aware of the compiler vendor's reluctance to make the changes.

It's not up to ANSI. they are but one of many panels that make up the
ISO C Working Group 14 that makes the decision.

 

[Chris Hills]

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?

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

Go fly your own damned kite.[/QUOTE]

Not at all he has a point. It is just that a few of you want to have a
different restrictive set of rules for this NG

We have been round this loop many many times. Many of us disagree with
your narrow interpretation of what this NG is for.

Relax and stop your anti LCC-win paranoia

 

[Chris Hills]

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


ANSI issued the first "official" C Standard, in 1989.

That was superseded in 1990 by ISO C

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.

It was. It was ANSI C compliant the year before ANSI published C

provide an early release of "ANSI C". The expression "ANSI C" has embedded
itself firmly in the minds of the C programming community.

Only with some.

Furthermore, the ISO standardisation of 1990 was little more than a
rubber-stamping exercise.

It was. (Since then the roles have reversed)

I think ISO's only contribution was to muddle up
the section numbers.

Yes. It was unfortunate that ISO left the rational out.

In a C context, ANSI and ISO are practically
synonyms.

Not at all. ISO is the standard. ANSI is the local US version I have
BSI-C I know people with DIN-C

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?

No. I assume ANSI is C89 not C95 or C99

 

[Richard Heathfield]

Chris Hills said:

That was superseded in 1990 by ISO C

Yes, Chris, I know - but not everybody *cares*, Chris. ISO people care,
obviously, and you're an ISO people, so obviously you care. And, to a
certain extent, I care too, although not as much as you, because I'm not
really an ISO people. But most people don't give a tinker's cuss. Lots of
people still call it "ANSI C", and they don't give a rat's wristwatch
whether we agree with them or not - they know it's called ANSI C because
it says so on the front of K&R2, and that's QED as far as they're
concerned.

It was. It was ANSI C compliant the year before ANSI published C


Only with some.

Fine - but it's a big "some". Certainly I'd never heard of "ISO C" until I
started reading comp.lang.c in 1998 or 1999 or something like that,
despite having been working alongside quite a few dozens of C programmers,
all told, within the industry in the previous not-quite-decade.

Nobody - but *nobody* - that I've ever met face to face, with the
*possible* exceptions of Chris Dollin and Ian Woods, calls it ISO C.

Not at all. ISO is the standard. ANSI is the local US version I have
BSI-C I know people with DIN-C

Fine, but everyone I ever worked with calls it ANSI C.

No. I assume ANSI is C89 not C95 or C99

Well, okay, but I assume ISO is C90, obviously, so that's a score-draw, I
think.

 

[Chris Dollin]

Nobody - but *nobody* - that I've ever met face to face, with the
*possible* exceptions of Chris Dollin and Ian Woods, calls it ISO C.

Old habits die hard.

I know it's ISO, but the knowing bit doesn't always wrest control away
from the knew bit.

My current tactic nowadays is to say/write "/Standard/ C", and hope that
won't lead to painful, inflammatory, and ultimately pointless arguments
about whether older Standards are Standards.

 

[Charlie Gordon]

My errors maybe, but not yours.

Well, I try and correct mistakes that I see, but I also have to tend to my
own chores.
I did not "agree" to post corrections to *all* of Jacobs's mistakes
instantly, I agreed that I considered "fair" that Richard would stop posting
derogatory comments if I did correct them within a reasonable time. Yet
there is so much useless noise on this group, regarding such silly things as
signature snipping, that I can't keep up with the flow at the moment. I
certainly will correct Richard mistakes as well and anyone else's if I see
them. And I welcome corrections to my mistakes too.

Regarding C enhancements, and GC in particular, I share Paul Hsieh's views
absolutely, and Jacob Navia's to a large extent. I think and have stated
already that it would be much more productive toward this common goal to
publish lcc-win32 and any other compiler implementing proposed extensions as
open source, under a well chosen licence. I am willing to discuss the
counterparts of this move and prove that it may even be in your financial
interests to make it.

As for the current discussion, GC could be configured to deal with malloc'd
memory both ways: either leaving the heap untouched (but scanning it for
references to the GC heap) or letting it handle the life cycle of objects
allocated with malloc, realloc, calloc (and strdup ;-). As a matter of
fact, Boehms GC can do that.

 

[Charlie Gordon]

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.

Point made.

But even THAT is too much for the regulars

But could you refrain from always adding the single last remark that keeps
the argument going ?
Removing the ironic stance from your posts would greatly enhance your
ability to convince the readers.

 

[Richard Heathfield]

Charlie Gordon said:

I did not "agree" to post corrections to *all* of Jacobs's mistakes
instantly,

Partly true - you rightly allowed yourself a reasonable time. But you did
agree to correct *all* of his mistakes (although obviously we can safely
exclude those that are corrected by others - no point in doubling up).

And yet you have not done so.

This is hardly your fault. It's practically impossible for any one person
to keep up with the volume.

I agreed that I considered "fair" that Richard would stop
posting
derogatory comments

I'm not sure that I agree that my comments are derogatory. Some, sure, out
of sheer exasperation - but mostly I seem to attract flak for correcting
his errors. The reason for my offer was simply to demonstrate that
/anyone/ - even you - would attract this flak if they corrected as many of
his errors as I have done in the past.

<snip>

 

[Charlie Gordon]

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

Patience is a cardinal virtue.

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.

The main difference I could see is the exhorbitant fee ISO is charging for
both the printed version and the downloadable pdf of the C99 Standard. ISO
charges CHF 342 for ISO/IEC 9899:1999 (that's more than USD 300 !) for each
of the printed and the pdf versions, possibly plus shipping. In contrast
the very same document can be downloaded from ANSI for a mere USD 18. Why
this document cannot be dowloaded for free beats common sense, especially
since the uptodate version is freely available from the working group
website.

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?

Right, and irony is unnecessary as well I suppose.

 

[Charlie Gordon]

Chris Hills said:


Yes, Chris, I know - but not everybody *cares*, Chris. ISO people care,
obviously, and you're an ISO people, so obviously you care. And, to a
certain extent, I care too, although not as much as you, because I'm not
really an ISO people. But most people don't give a tinker's cuss. Lots of
people still call it "ANSI C", and they don't give a rat's wristwatch
whether we agree with them or not - they know it's called ANSI C because
it says so on the front of K&R2, and that's QED as far as they're
concerned.


Fine - but it's a big "some". Certainly I'd never heard of "ISO C" until I
started reading comp.lang.c in 1998 or 1999 or something like that,
despite having been working alongside quite a few dozens of C programmers,
all told, within the industry in the previous not-quite-decade.

Nobody - but *nobody* - that I've ever met face to face, with the
*possible* exceptions of Chris Dollin and Ian Woods, calls it ISO C.




Fine, but everyone I ever worked with calls it ANSI C.


Well, okay, but I assume ISO is C90, obviously, so that's a score-draw, I
think.

Could we just leave it as Standard C ?

 

[Charlie Gordon]

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.

ITYM 64 bit integers ?

 

[jacob navia]

Charlie Gordon said:



Partly true - you rightly allowed yourself a reasonable time. But you did
agree to correct *all* of his mistakes (although obviously we can safely
exclude those that are corrected by others - no point in doubling up).

And yet you have not done so.

This is hardly your fault. It's practically impossible for any one person
to keep up with the volume.


I'm not sure that I agree that my comments are derogatory. Some, sure, out
of sheer exasperation - but mostly I seem to attract flak for correcting
his errors. The reason for my offer was simply to demonstrate that
/anyone/ - even you - would attract this flak if they corrected as many of
his errors as I have done in the past.

<snip>

poor heathfield... in what a predicament he is

sniff!



at least this group is funny sometimes!

 

[Charlie Gordon]

Generally object-orientation is more trouble than its worth. But one
exception is streams. Serialisation is so fundamental that it should be
built in. You might want to look at my serialisation pages.
gets() is something and nothing. Yes it is an easy way to make a broken
program, but it is only one function, not a methodology.

The other problem is the dependency feature. Time after time code which
could be reusable actually pulls in three of four headers, which pull in
an entire library, often for something totally trivial, such as a Point3d
type.

Another one, which you will realise if you use Lisp, is that in C there
are too many ways to express the same thing - arrays of arrays of
structures with arrays, or lists of list of lists. Lisp handles it fine by
simply having one "list" structure. In C you are constantly checking - is
it a pointer or a nested array, where is the size member ?

a countof operator/macro that would fail on non arrays would be a welcome
extension!

 

[Richard Heathfield]

Charlie Gordon said:

"Malcolm McLean" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...


ITYM 64 bit integers ?

Whichever he means, he doesn't need to campaign. All he has to do is use
any of the vast[1] number of implementations whose designers agree with
him that 64 bit int[eger]s are the way forward. C itself does not mandate
64 bit int[eger]s, but it doesn't forbid them either, so if it's a
technically sensible thing to do, you can be sure that lots of
compiler-writer techies will already have done it.

[1] For a certain value of "vast".

 

[Mark McIntyre]

poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much.
It seems that you /always/ post a rude or sarcastic final word,
insulting someone.