[Qemu-devel] OT: C Q/As, was Re: security_20040618

[Charlie Gordon]

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