New book - 'C of Peril'

[Paul L Daniels]

Hello All,

I've been compiling a series of pages about the bad functions and
mistakes that occur in C into a book, subsequently, I now have a moderate
little book of about 32 pages available for download as a PDF file at

http://www.pldaniels.com/c-of-peril

It's currently still being worked on and I'm always seeking out new
examples of C being used poorly or broken standard functions.

Regards.

--
PLDaniels - Software - Xamime
Unix systems Internet Development A.B.N. 19 500 721 806
PGP Public Key at http://www.pldaniels.com/gpg-keys.pld

[Keith Thompson]

Keith Thompson <ks***@mib.or g> writes:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> writes:

[...]

6: "programmin g ... is not the place to express creativity ..."
Obviously you have never programmed!

But there is a valid point there. Certain forms of "creativity " are
inappropriate. (I'd expound further if I had time.)

What I was thinking of was number 8 from Henry Spencer's "The Ten
Commandments for C Programmers":

Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest
it not, for thy creativity is better used in solving problems than
in creating beautiful new impediments to understanding.

(The "One True Brace Style" refers to the style used in K&R; even if
you prefer a different style, the point is a good one.)

<http://www.lysator.liu .se/c/ten-commandments.ht ml>

(Certainly the idea that programming is not the place to express
creativity is ludicrous. Programming isn't just an art, but neither
is it a science; it's a craft.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Nils O. Selåsdal <NO*@Utel.no> writes:

On Sun, 05 Dec 2004 05:11:38 +0000, Rouben Rostamian wrote:

[...]

I free() NULL pointers frequently and intentionally. Here is a sample:

You are aware this will utterly f*** up things on many platforms ?
I wouldn't advocate this knowing that it may break if I were you ...

[edited for content]

Many platforms? Name three.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[dandelion]

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...

<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.

Introducing Garbage Collection in C wil render the language useless to any
application-developer in need of (hard) Real Time. That *would* be a pity.

[jacob navia]

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...

<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.

Introducing Garbage Collection in C wil render the language useless to any
application-developer in need of (hard) Real Time. That *would* be a pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

jacob

[dandelion]

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...

<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.

Introducing Garbage Collection in C wil render the language useless to any application-developer in need of (hard) Real Time. That *would* be a pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

And the garbage collection routine? At some point some GC will need to
be done.

[jacob navia]

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41***** *************** ***@news.wanado o.fr...

<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.
Introducin g Garbage Collection in C wil render the language useless to
any
applicatio n-developer in need of (hard) Real Time. That *would* be a
pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

And the garbage collection routine? At some point some GC will need to
be done.

It is done at each allocation.
There are several levels: mini-gcs, full gc, etc.

[CBFalconer]

jacob navia wrote:

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message

<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of
other solutions too.

Introducing Garbage Collection in C wil render the language
useless to any application-developer in need of (hard) Real Time.
That *would* be a pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

Those redefinitions are specifically forbidden by the standard, and
for good reasons, which in turn should be obvious to any
implementor.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

Those redefinitions are specifically forbidden by the standard, and
for good reasons, which in turn should be obvious to any
implementor.

That is in the case you want to replace all your calls to
malloc with the gc (a sensible solution)

You are not forced to do that, since you can always explicitely
call GC_malloc. You should never call free however, because if
you call free with a GC_malloced object chaos will ensue.

Those errors can be very difficult to catch, hence the proposed defines.
jacob

[Keith Thompson]

jacob navia <ja***@jacob.re mcomp.fr> writes:

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41******** *************** @news.wanadoo.f r...
<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.

Introducing Garbage Collection in C wil render the language useless
to any
application-developer in need of (hard) Real Time. That *would* be a pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

Apart from the legality questions of redefining malloc(), wouldn't you
want a GC_free() routine as well? After free(a), the variable "a"
will still contain a copy of the (now indeterminate) pointer.
Presumably that would prevent the garbage collector from collecting
memory indirectly pointed to by "a". (The program could set a to
NULL, but that's an extra requirement.)

It's not true that there are no language modifications whatsoever.
Values, including pointers, are made of bytes, which are made of bits.
A strictly conforming program can convert a pointer to an array of
unsigned char, destroy the original pointer value, complement the
unsigned char values, go off and do some other stuff, then reconsitute
the pointer from the scrambled bytes and dereference it. If GC is
being used, once the pointer value doesn't exist in its original form
the system can deallocate whatever it points to.

That's not to say that it would be unreasonable to provide garbage
collection in a C implementation, but it would be a change in the
semantics of the language.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.re mcomp.fr> writes:

dandelion wrote:

"jacob navia" <ja***@jacob.re mcomp.fr> wrote in message
news:41***** *************** ***@news.wanado o.fr...
<snip>

same for the eternal free/realloc/malloc problems. I have been
arguing here for a GC based solution, and there is a lot of other
solutions too.

Introducin g Garbage Collection in C wil render the language useless
to any
applicatio n-developer in need of (hard) Real Time. That *would* be a pity.

There is no "introducti on of garbage collection" in the language itself!

The standard library isn't changed either.

The only thing that changes is

#define malloc(a) GC_malloc(a)
#define free(a)

There are no language modifications whatsoever.

Apart from the legality questions of redefining malloc(), wouldn't you
want a GC_free() routine as well? After free(a), the variable "a"
will still contain a copy of the (now indeterminate) pointer.
Presumably that would prevent the garbage collector from collecting
memory indirectly pointed to by "a". (The program could set a to
NULL, but that's an extra requirement.)

There *is* a GC_free routine, but its use is not really recommended.
Sometimes it can be useful to use it when you are 100% sure that a
memory block will never be used again.

If we would have to use GC_free, the utility of an automatic GC would
be greatly reduced...

It's not true that there are no language modifications whatsoever.
Values, including pointers, are made of bytes, which are made of bits.
A strictly conforming program can convert a pointer to an array of
unsigned char, destroy the original pointer value, complement the
unsigned char values, go off and do some other stuff, then reconsitute
the pointer from the scrambled bytes and dereference it. If GC is
being used, once the pointer value doesn't exist in its original form
the system can deallocate whatever it points to.

If you use the GC you have to leave the bits in the pointers as they
are. If you hide them, the block could be collected if there are no
other references to it.

This is a "change" in the way you use pointers (maybe, the case you
mention is highly hypotetical), since you can't store them on disk,
or in the "windows extra bytes" (where the collector doesn't look),
or Xor them and expect the pointer to still be valid afterwards.

This is a limitation of the collector/compiler.

A clever compiler would see what you are doing and store a hidden copy
of the pointer somewhere :-)
That's not to say that it would be unreasonable to provide garbage
collection in a C implementation, but it would be a change in the
semantics of the language.

The fact that you shouldn't store the pointers to live objects in
the disk or change their value is a "semantic change to the language" ???

Those kind of operations with pointers are quite rare, and I have
never seen them. But yes, if you insist, there *are* some limitations
and constraints imposed to you, as with any other software that you use.

For 99.9999 % of the applications, where pointers are stored normally
in local variables or in data structures, nothing changes.

Please bear in mind that I am not telling "GC is the best thing since
sliced bread". I am not a salesman. The GC can be useful in many
applications and relieves you from the terrible problems of making
errors in malloc/free, what is a big advantage.

But it can produce errors if you keep unneeded pointers around, errors
that are very difficult to track! I would not recommend it in real
time systems either, but those systems do not use even the "malloc"
system call anyway.

In many PC applications however, it gives the C language a huge
advantage, simplifying the applications, simplifying the programming.

jacob