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

[Malcolm]

"CBFalconer " <cb********@yah oo.com> 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)?

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

The fault lies with the language, rather than the original programmer.

Some construct such as #define foo(x,y){ code(x); morecode(y); } should be
used to define multi-line macros. Whoever designed the original preprocessor
forgot to include any support, and so we are stuck with the do while
workaround.

As for being a well-known method, it is a little quirk that experienced C
programmers will eventually pick up, but might puzzle programmers who only
use C rarely.

[Keith Thompson]

"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:

"CBFalconer " <cb********@yah oo.com> 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)?
>> As far as reading the original macro definition is concerned, this
is a well known method, and should not cause any concern
whatsoever.

The fault lies with the language, rather than the original programmer.

Some construct such as #define foo(x,y){ code(x); morecode(y); } should be
used to define multi-line macros. Whoever designed the original preprocessor
forgot to include any support, and so we are stuck with the do while
workaround.

The preprocessor expands macro invocations to arbitrary sequences of
tokens; it has no concept of higher-level constructs such as
statements and blocks. This makes it both powerful and dangerous.

It's not the preprocessor's fault that

#define foo(x,y){ code(x); morecode(y); }

doesn't always work. It's a consequence of the grammar of the
language itself, specifically the fact that a block cannot always be
substituted for a statement.
As for being a well-known method, it is a little quirk that experienced C
programmers will eventually pick up, but might puzzle programmers who only
use C rarely.

The "do { ... } while(0)" idiom is obscure at first glance, but *is*
well-known, and any C programmer should be able to understand it.
It's even in the FAQ (10.4). Programmers who only use C rarely are
likel to have bigger problems than understanding a do-while loop in a
macro definition.

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

[Paul L Daniels]

On Tue, 7 Dec 2004,Arthur J. O'Dwyer wrote:

list Arthur as a "Contributo r" and credit him ;-)

Bah. You asked for corrections, and I supplied some. No worries.

Exactly. I do believe it would be only fair that you are duly noted in
the credits since you did provide quite an number of corrections.

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

[Lawrence Kirby]

On Mon, 06 Dec 2004 21:51:03 +0000, CBFalconer wrote:

jacob navia wrote:

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.

As I said, the proposed defines themselves are illegal.

Only as part of program code. Just arrange for this to be considered part
of the implementation and that problem goes away.

Lawrence

[Dan Pop]

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

On Tue, 7 Dec 2004, Dan Pop wrote:

ro****@pc18.mat h.umbc.edu (Rouben Rostamian) writes:

#define foo(x) { bar(x); baz(x); }

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

Why bother?

#define foo(x) (bar(x), baz(x))

What if 'bar' and 'baz' are statement-like macros in their own right?

Unless the description of the problem *explicitly* mentions this
possibility, there is no point in bothering to work around it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[CBFalconer]

Lawrence Kirby wrote:

On Mon, 06 Dec 2004 21:51:03 +0000, CBFalconer wrote:

jacob navia wrote:

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.

As I said, the proposed defines themselves are illegal.

Only as part of program code. Just arrange for this to be
considered part of the implementation and that problem goes away.

True, but so does standards conformance. See the "obfuscated
pointer" problem mentioned elsethread. The result is just another
bastard language.

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

[Lawrence Kirby]

On Wed, 08 Dec 2004 15:26:36 +0000, CBFalconer wrote:

....

Only as part of program code. Just arrange for this to be
considered part of the implementation and that problem goes away.

True, but so does standards conformance. See the "obfuscated
pointer" problem mentioned elsethread. The result is just another
bastard language.

Indeed, which is why I stressed it with "that" problem. Clearly there are
other problems which do not go away.

Lawrence