|
From: | Christof Petig |
Subject: | Re: [Qemu-devel] OT: C Q/As, was Re: security_20040618 |
Date: | Mon, 21 Jun 2004 12:41:58 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux ppc; de-AT; rv:1.6) Gecko/20040414 Debian/1.6-5 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |