From mboxrd@z Thu Jan 1 00:00:00 1970 From: Riley Williams Subject: Re: C compiler, assembler and linker Date: Tue, 23 Jul 2002 01:34:21 +0100 (BST) Sender: linux-8086-owner@vger.kernel.org Message-ID: References: <1c289c8ad98ba628@mayday.cix.co.uk> Reply-To: Riley Williams Mime-Version: 1.0 Return-path: In-Reply-To: <1c289c8ad98ba628@mayday.cix.co.uk> List-Id: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Robert de Bath Cc: Manuel Novoa III , Linux-8086 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. >> 2) #warning support (at least for non-continued lines). > Hmm, a bit primitive, but, wth, It'll do the job. >> 3) Support asm() at file scope. This is to allow the equivalent >> of #asm/#endasm in macros. > Hmm, interesting, I'll have to look at this ... carefully. >> 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. > 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... Best wishes from Riley.