Re: C compiler, assembler and linker

[mjn3@codepoet.org (Manuel Novoa III)]

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