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

[Christof Petig <christof@petig-baender.de>]

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