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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).