[net.micro.amiga] Manx Compiler +l bug

phils@tekigm.UUCP (Phil Staub) (10/24/86)

< --------------------------->


While trying to compile the MicroEMACS 3.7 sources with the Manx 3.20a
compiler, I ran into a problem with the #if'd code used to select
machine/compiler/os environment.

Problem:
	Error #109's to say that the if values need to be integer
	constants, but only if I compile with 32 bit ints. Compilation with
	16 bit ints works as expected.

To reproduce:
	Compile the program below with

		cc foo.c

	This works, while

		cc +l foo.c

	fails.

Questions:
	1. Has anyone else seen this behavior?
	2. Has anyone found a work around?
	3. Does the 3.30 compiler do the same thing?

Thanks,

Phil Staub
Tektronix, Inc.
ISI Engineering
P.O. Box 3500
Vancouver, Washington 98668
C1-904, (206) 253-5634
..tektronix!tekigm!phils
-------------------------------------------------------------------------------

/* set/clear these values to turn the messages below on or off */
#define A	0
#define B	0
#define C	0
#define D	0
#define E	0
#define F	0

main()
{
#if A
	printf("A is set\n");
#endif
#if B
	printf("B is set\n");
#endif
#if C
	printf("C is set\n");
#endif
#if A | B
	printf("A is set\n");
	printf("B is set\n");
#endif
#if A | C
	printf("A is set\n");
	printf("C is set\n");
#endif
#if B | C
	printf("B is set\n");
	printf("C is set\n");
#endif
#if A | B | C
	printf("A is set\n");
	printf("B is set\n");
	printf("C is set\n");
#endif
#if A | B | C | (D & (E | F))
	printf("composite\n");
#endif
}

swalton@well.UUCP (Stephen R. Walton) (10/29/86)

In article <988@tekigm.UUCP> phils@tekigm.UUCP (Phil Staub) writes:

>While trying to compile the MicroEMACS 3.7 sources with the Manx 3.20a
>compiler, I ran into a problem with the #if'd code used to select
>machine/compiler/os environment.
>
>Problem:
>	Error #109's to say that the if values need to be integer
>	constants, but only if I compile with 32 bit ints. Compilation with
>	16 bit ints works as expected.

and then an example using #if with operators & and |.  Short answer:  yes,
it's a bug, to be fixed on the next release of Aztec C.  Longer answer:
for a good fix, albeit a bit slow, try the port of the Decus preprocessor
on Fish disk 28;  there is a cc command which invokes this cpp and the
Aztec compiler in sequence.