From mboxrd@z Thu Jan 1 00:00:00 1970 From: mjn3@codepoet.org (Manuel Novoa III) Subject: Re: C compiler, assembler and linker Date: Mon, 22 Jul 2002 18:58:21 -0600 Sender: linux-8086-owner@vger.kernel.org Message-ID: <20020723005821.GB9657@codepoet.org> References: <1c289c8ad98ba628@mayday.cix.co.uk> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Riley Williams Cc: Robert de Bath , Linux-8086 Riley, On Tue, Jul 23, 2002 at 01:34:21AM +0100, Riley Williams wrote: > Hi Robert, Manuel. > > >> 1) #elif support. > > > Okay, reasonable. > > I haven't had a chance to look at this yet, so this comment is probably > irrelevant, but...does this support handle the following correctly? > > #define MODE1 > #define MODE3 > > #ifdef MODE1 > # ifdef DEBUG > # define DBGMODE 1 > # endif > #elifdef MODE2 > # define DBGMODE 2 > #elifdef MODE3 > # define DBGMODE 3 > #else > # define DBGMODE 4 > #endif > > #ifndef DBGMODE > # define DBGMODE 0 > #endif > > With at least one C compiler I've used over the years, DBGMODE ended up > with the value 3 rather than the value 1 that it should have in that case. I just tested. Changing #elifdef to #elif defined( ), it gives 0 if DEBUG isn't defined, and 1 if DEBUG is defined. > >> 4) Limited support for things like "#define stdio stdio". Stock bcc > >> goes into an infinite loop when encounting this. The implementation > >> has flaws, but it does what I needed. You see this a lot in the > >> glibc headers we're using with uClibc (yes I'm working on a port). > > One obvious optimisation is this: Where a #define has the same value for > its value as its name, the entire #define is treated as a comment. That > would deal with the above define, but could have problems with... > > #define stdio (stdio) > > ...which probably also fails with the old system. Treating the define as a comment wouldn't work, as all the subsequent #ifdef stdio tests would fail. > > I don't like the way this is done; I think it'd be better to > > 'smudge' the definition of the current macro so that the search > > can't find the word for recursion. > > When are macros expanded? If they are expanded as they are met in the > code, the above can't cause a problem as the macro isn't defined until > after the value has been expanded. However, if the preprocessor reaps > all the macros and then expands them in a separate pass, recursion > problems are inevitable. > > As an example of this, how is the following code handled? > > int main() > { > int VALUE = 7; > > #define VALUE 12 > > printf("Test 1 = %d\n", VALUE ); > > #undef VALUE > > printf("Test 2 = %d\n", VALUE ); > exit(0); > } > > Whilst not good coding, that code is perfectly valid K&R C but any > compiler that first reaps the #define/#undef statements and expands the > macros in a separate pass can produce faulty code in two different ways, > and can fail to compile in two other ways... Preprocessor output: int main() { int VALUE = 7; printf("Test 1 = %d\n",12 ); printf("Test 2 = %d\n",VALUE ); exit(0); } Manuel