From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1BcLvL-00021b-Lp
	for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:21:11 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1BcLvJ-00021O-Nr
	for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:21:11 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1BcLvG-00021B-VS
	for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:21:07 -0400
Received: from [80.91.224.249] (helo=main.gmane.org)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1BcLtg-0006pb-Fz
	for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:19:28 -0400
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1BcLtf-0002V4-00
	for <qemu-devel@nongnu.org>; Mon, 21 Jun 2004 12:19:27 +0200
Received: from dyn-83-157-93-194.ppp.tiscali.fr ([83.157.93.194])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Mon, 21 Jun 2004 12:19:27 +0200
Received: from gmane by dyn-83-157-93-194.ppp.tiscali.fr with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Mon, 21 Jun 2004 12:19:27 +0200
From: "Charlie Gordon" <gmane@chqrlie.org>
Date: Mon, 21 Jun 2004 12:21:46 +0200
Message-ID: <cb6cnc$akt$1@sea.gmane.org>
References: <20040619150514.GB1962@sentinelchicken.org><cb4kh5$e20$1@sea.gmane.org>	<20040620192652.GA1927@sentinelchicken.org><cb4qqb$qi2$1@sea.gmane.org>
	<40D6A164.2010109@petig-baender.de>
Sender: news <news@sea.gmane.org>
Subject: [Qemu-devel] OT: C Q/As, was Re: security_20040618
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> > one of my favorite Q/As : what is wrong with : enum BOOL { FALSE=0,
> > TRUE=1 }; ?
>
> can you enlighten me? The only drawback I see is that with plain C (no
> C++) typedef enum { ... } BOOL; would be more appropriate.
>
defensive programming would require that TRUE be also defined as

#define TRUE 1

as many unsuspecting programmers will expect TRUE and FALSE to be handled in
the preprocessor phase eg:

#if TRUE
    ...
    somecode();
    ...
#endif

if TRUE is defined solely as en enum value, it will expand to 0 inside
preprocessing directive expressions without warning : quite a headache to
debug this type of mistake !


> PS: I used to ask: Why does this crash later (if you are lucky)
>
> const char *itoa(int i)
> {  char x[20];
>     snprintf(x,sizeof x,"%d",i);
>     return x;
> }

This code will abviously fail, unless you are very lucky and use the
returned value right away, as the x buffer is in automatic stack space and
will be overwritten by subsequent function calls or possibly signal
handlers.

I can think of 4 ways it may crash later when the pointer is dereferenced :
- you are using an advanced C compiler/runtime that checks pointer validity
(such as valgrind, checker, tinycc...)
- after the end of the thread that called itoa.
- if pages in the stack are unmapped for another reason like the stack being
swapped out and having shrunk below the depth it had when itoa was called
(quite unlikely).
- if the stack contains no zero byte till the end of its mapped space (you
would have to be so lucky for this!)

Anything more casual ?

Charlie, the C teaser.