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

[Christof Petig]

Charlie Gordon schrieb:
> > > 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 !

Thank you, I did not think of #if as a target for TRUE. That explains 
the numerous defines in gtk+ (instead of using enums).

Do you know what happens if you use '#define XYZ TRUE \n #if XYZ == 
TRUE' [If I read your answer correctly both == TRUE and == FALSE would 
be true :-( ]

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

Oh I did not expect you to answer the obvious (to me). I just wanted to 
share my old would-be-employee test.

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

can valgrind really check it if you dereference the pointer in a 
subroutine deeply enough to reuse the memory again?

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

that's more than I ever expected ;-) You are right, crashing is far more 
unlikely than giving strange characters. If you rely on the length or 
content of the string returned, that might easily lead to a crash (if 
you make other mistakes).

actually knowing that a static will fix the bug (but introduce new 
problems) should be enough for most C programmers.

    Christof