From: "Charlie Gordon" <gmane@chqrlie.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] OT: C Q/As, was Re: security_20040618
Date: Mon, 21 Jun 2004 12:21:46 +0200 [thread overview]
Message-ID: <cb6cnc$akt$1@sea.gmane.org> (raw)
In-Reply-To: 40D6A164.2010109@petig-baender.de
> > 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.
next prev parent reply other threads:[~2004-06-21 10:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200406181841.i5IIfZQa019337@treas.simtreas.ru>
2004-06-19 7:33 ` [Qemu-devel] Errors compiling QEMU with Mingw Vladimir N. Oleynik
2004-06-19 7:37 ` [Qemu-devel] [PATCH] security_20040618 Vladimir N. Oleynik
2004-06-19 15:05 ` Tim
2004-06-20 18:22 ` [Qemu-devel] " Charlie Gordon
2004-06-20 19:26 ` Tim
2004-06-20 20:10 ` [Qemu-devel] " Charlie Gordon
2004-06-20 21:57 ` Tim
2004-06-21 8:50 ` OT: C Q/As, was Re: [Qemu-devel] security_20040618 Christof Petig
2004-06-21 10:21 ` Charlie Gordon [this message]
2004-06-21 10:41 ` [Qemu-devel] OT: C Q/As, was security_20040618 Christof Petig
2004-06-21 15:44 ` OT: C Q/As, was Re: [Qemu-devel] security_20040618 Michael Jennings
2004-06-22 9:57 ` [Qemu-devel] Re: completely OT: C Q/As, was security_20040618 Charlie Gordon
2004-06-22 10:49 ` Sander Nagtegaal
2004-06-22 12:37 ` [Qemu-devel] " Charlie Gordon
2004-06-22 15:38 ` [Qemu-devel] Re: completely OT: C Q/As Michael Jennings
2004-06-24 14:21 ` [Qemu-devel] Re: Re: completely OT: C Q/As : let's feed the troll Charlie Gordon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='cb6cnc$akt$1@sea.gmane.org' \
--to=gmane@chqrlie.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.