From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BcMHO-0007Ir-QZ for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:43:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BcMHO-0007If-0K for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:43:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BcMHN-0007Ic-UY for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:43:57 -0400 Received: from [62.53.231.247] (helo=e.frontend.um.mediaways.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1BcMG4-0003D4-Am for qemu-devel@nongnu.org; Mon, 21 Jun 2004 06:42:36 -0400 Message-ID: <40D6BB76.9080803@petig-baender.de> Date: Mon, 21 Jun 2004 12:41:58 +0200 From: Christof Petig MIME-Version: 1.0 Subject: Re: [Qemu-devel] OT: C Q/As, was Re: security_20040618 References: <20040619150514.GB1962@sentinelchicken.org> <20040620192652.GA1927@sentinelchicken.org> <40D6A164.2010109@petig-baender.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Charlie Gordon 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