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

[Trent Buck]

Up spake Paul L Daniels:

Incidentally, that introductory paragraph shows about the quality of
English writing we can expect from the whole book --- not so hot.
Never claimed it to yet be an exercise in English literature.

That is not a valid excuse for spelling or grammar mistakes, or
ambiguous or poor wording.
The book is incomplete and will go through an editing phase by 3rd
parties.

....but this is. While couched a little over-aggressively, the OP's
criticism is valid, and a significant portion of the prose needs to be
rewritten for clarity.

--
-trent
Math is for kids who can't get by on looks and trench coats alone.

[jacob navia]

Paul L Daniels wrote:

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.

This examples aren't strictly new...

Many solutions have been proposed, and it wouldn't hurt if you would
review the literature and tell the reader what has been done to addres
this problems.

The string handling of C, designed more than 3 decades ago, is obviously
a very weak feature of the language, as we have discussed repeatedly
here. Microsoft, (to name one) has proposed a safer string library, and
many other people have proposed others.

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

If you want to contribute something more interesting than an old rehash
of previous discussions, a review of the literature is necessary.
jacob

[Malcolm]

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

#define foo(x) do { bar(x); baz(x); } while(0)

Anyone know if there's a way to do this without relying on do/while/if/for (etc)?

Nope. But why does it matter? 'do' is just as much a part of the
language as the left parenthesis, and it always has been.

It's a minor irritation.
By itself it doesn't matter much, but the cumulative effect of many minor
irritations is that code becomes hard to read, and thus more expensive to
maintain.

[Keith Thompson]

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

2.3: C++ programmers will not like that you use a struct with the
same name as a function.
In a document about C, there's not much reason to care whether C++
programmers will like it or not. On the other hand, C programmers may
dislike it because it's confusing, even if it's perfectly legal.

2.4: Why 'CP_strncpy' but 'zstrncat'? Is there a method to your
naming convention?
Several of your single-line comments spill over and become syntax
errors; this is exactly why Real Programmers[tm] do not use C++-style
comments.
The best reason to avoid C++-style comments is that they're not (yet)
portable. C++ and C99 support them; C90 does not, though many pre-C99
compilers do support them as an extension.

"//" comments can be a problem in Usenet postings because there are
points between writing the code and reading it where long lines can be
quietly folded by client software that assumes it's dealing with
paragraphs rather than source code. (The same thing can happen with
string literals and macro definitions, but it's the comments that
people complain about.) This shouldn't be an issue in a document like
a PDF file where you (theoretically) control the formatting yourself.

<OT>
Some languages, such as Perl and Ada, only support comments introduced
by a delimiter and terminated by the end of a line. Personally, I
like that better than C's "/* ... */" comments. If "//" comments were
portable in C, I'd probably use them in preference to "/* ... */"
comments. YMMV.
</OT>

[...]
Listing 3.3 is labeled "Example of segmentation faulting using free,"
but it does not exhibit a segfault --- it's perfectly valid. Remove
the '= NULL' initializer and you've got a case.
But even then, a segfault (whatever that is; C doesn't define the
term) is only one possible consequence of undefined behavior.

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

And "obsfuscate d" is misspelled.

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

[Alex Wade]

I'm sorry, but I think you need to do a great deal of proofreading and
correct your spelling, grammar and style. I gather from the number of
errors in the English that it is probably not your first language. Perhaps
you should have somebody who speaks English proofread and correct the
document for you.

[CBFalconer]

Malcolm wrote:

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

#define foo(x) do { bar(x); baz(x); } while(0)

Anyone know if there's a way to do this without relying on
do/while/if/for (etc)?

Nope. But why does it matter? 'do' is just as much a part of
the language as the left parenthesis, and it always has been.

It's a minor irritation. By itself it doesn't matter much, but
the cumulative effect of many minor irritations is that code
becomes hard to read, and thus more expensive to maintain.

Not at all. The purpose of using it is exactly the opposite - to
allow the macro to be used in normal C contexts without creating
obscure syntax errors in the final code, or requiring special
considerations such as adding or omitting semicolons.

As far as reading the original macro definition is concerned, this
is a well known method, and should not cause any concern
whatsoever.

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

[Arthur J. O'Dwyer]

On Sun, 5 Dec 2004, Keith Thompson wrote:

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

2.3: C++ programmers will not like that you use a struct with the
same name as a function.
In a document about C, there's not much reason to care whether C++
programmers will like it or not. On the other hand, C programmers may
dislike it because it's confusing, even if it's perfectly legal.

I was being conservative. I imagine /some/ C programmers would like it,
and not think it's confusing at all --- I see why the OP did it, since the
struct is only being used in conjunction with that one function. But it
might confuse C programmers who are /also/ C++ programmers. :)
<OT>
Some languages, such as Perl and Ada, only support comments introduced
by a delimiter and terminated by the end of a line. Personally, I
like that better than C's "/* ... */" comments. If "//" comments were
portable in C, I'd probably use them in preference to "/* ... */"
comments. YMMV.
</OT>

MMDV, yes. Too many formatting pitfalls; also, I like to write block
comments and dislike too many scattered single-line comments.

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

Certain forms, yeah, but that's a different point. The OP's sentence
was as ridiculous as claiming that "literature is no place for creativity"
just because some people can't spell right!

-Arthur

[Nils O. Selåsdal]

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

In article <pa************ *************** *@pldaniels.com >,
Paul L Daniels <pl*******@plda niels.com> wrote:

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.

I looked quickly through your writeup. It's pretty good.
Here are my remarks on a couple of items that sort of jumped at me.

1.
On the section on free() you wrote:

Certainly it is agreeable that if you are attempting to free a
null pointer, then you're most certainly in a situation where
somewhere prior in your code there is something amiss.

Certainly it is agreeable? Not!

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

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

[jacob navia]

Nils O. Selåsdal wrote:

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

[snip]

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

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

Please:
<Quote>
The C standard page 312
7.20.3.2 The free function
Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation.
If ptr is a null pointer, no action occurs.
</quote>

[Rouben Rostamian]

In article <pa************ *************** *@Utel.no>,
Nils O. Selåsdal <NO*@Utel.no> wrote:

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 fuck up things on many platforms ?
I wouldn't advocate this knowing that it may break if I were you ...

free(NULL) is perfectly harmless; it's required to be so by
the C standard.

If your platform is broken, change the platform. Don't ask
me to change my good code to accommodate your bad platform.

--
Rouben Rostamian