🚀 go-pugleaf

I'm curious about the differences between `normal' gcc and when using the
`-traditional' switch.  I see things that aren't mentioned in the gcc manual
page.  For example:

[ Aside: no SunView flames, please - I use X11R2 95% of the time
  on my own Sun-3; a disk error crunched some programs and I'm using the
  source to rebuild them instead of restoring from the release tapes - GKE  ]

Most SunView programs use the following construct to create icons:

	static short icon_image[] = {
	#include <images/someimagefromiconedit.icon>
	};
	mpr_static(icon_pixrect, 64, 64, 1, icon_image);

This construct seems to annoy gcc quite a bit, but using the `-traditional'
switch makes gcc perfectly happy.  For example, try building the `clock'
program (sources are in /usr/src/sun/suntool; anyone can do this); I used
gcc v1.29 (vanilla) on a Sun-3/160 running SunOS 4.0:

poseur:2:88 # make -n clock
gcc -v -c -O -DSTANDALONE clock.c
gcc -v -c -O -DSTANDALONE clockhands.c
gcc -v -c -O -DSTANDALONE clockhands.rom.c
gcc -v -O clock.o clockhands.o clockhands.rom.o -o clock -lsuntool -lsunwindow -lpixrect -lrpcsvc -lm

poseur:2:89 # gcc -v -c -O -DSTANDALONE clock.c
gcc version 1.29
 /usr/local/lib/gcc-cpp -v -DSTANDALONE -undef -D__GNU__ -D__GNUC__ -Dmc68000 -Dsun -Dunix -D__OPTIMIZE__ -D__HAVE_68881__ -Dmc68020 clock.c /tmp/cca00375.cpp
GNU CPP version 1.29
/usr/include/suntool/panel.h:35: warning: garbage at end of #ifdef argument
/usr/include/suntool/panel.h:185: warning: garbage at end of #ifdef argument
 /usr/local/lib/gcc-cc1 /tmp/cca00375.cpp -quiet -dumpbase clock.c -O -version -o /tmp/cca00375.s
GNU C version 1.29 (68k, MIT syntax) compiled by GNU C version 1.29.
clock.c:46: parse error before `_data'
clock.c:46: initializer for scalar variable requires one element
clock.c:46: warning: data definition lacks type or storage class
clock.c:46: parse error before `_data'
clock.c:51: parse error before `_data'
clock.c:51: redefinition of `_data'
clock.c:46: previous declaration of `_data'
clock.c:51: initializer for scalar variable requires one element
clock.c:51: warning: data definition lacks type or storage class
clock.c:51: parse error before `_data'
clock.c: In function clock_update_tmp:
clock.c:397: warning: `clock_update_tmp' was declared implicitly `extern'
and later `static'

poseur:2:90 # gcc -v -c -O -traditional -DSTNDALONE clock.c
gcc version 1.29
 /usr/local/lib/gcc-cpp -v -DSTANDALONE -undef -D__GNU__ -D__GNUC__ -Dmc68000 -Dsun -Dunix -D__OPTIMIZE__ -traditional -D__HAVE_68881__ -Dmc68020 clock.c /tmp/cca00388.cpp
GNU CPP version 1.29
 /usr/local/lib/gcc-cc1 /tmp/cca00388.cpp -quiet -dumpbase clock.c -O -traditional -version -o /tmp/cca00388.s
GNU C version 1.29 (68k, MIT syntax) compiled by GNU C version 1.29.
 as -mc68020 /tmp/cca00388.s -o clock.o

poseur:2:91 #

Here's the code context (lines 46, 51 included):

poseur:2:91 # sed -n '42,52p' clock.c

static  u_short icon_data[300] = {
#include <images/clock.icon>
};
mpr_static(clock_default_mpr, 64, 75, 1, icon_data);		Line 46

static u_short icon_rom_data[300] = {
#include <images/clock.rom.icon>
};
mpr_static(clock_default_rom_mpr, 64, 75, 1, icon_rom_data);	Line 51

-------------------------------------------------------------------------

`mpr_static' is a macro (defined in <pixrect/memvar.h>) that looks like this:

/* First a pair of utility macros that allow concatenation in a fashion that
 * won't annoy lint (These belong in a standard header file!):
 */
#ifndef CAT
#undef  IDENT
#define IDENT(x)        x
#define CAT(a,b)        IDENT(a)b
#endif

#define mpr_static(name, w, h, d, image) \
	struct mpr_data CAT(name,_data) = \
		{mpr_linebytes(w,d), (short *)(image), {0, 0}, 0, 0}; \
	Pixrect name = {&mem_ops, w, h, d, (caddr_t)&CAT(name,_data)}

-------------------------------------------------------------------------

It looks like normal gcc doesn't like the Sun `CAT' macro, and therefore
refuses to concatenate the `clock_default_mpr' with `_data', thus leaving a
space between them (the output from gcc-cpp is
	# 44 "clock.c"

};
struct mpr_data clock_default_mpr _data  = {( ... )

whereas `-traditional' gcc concatenates them OK.  gcc also seems to not
like non-alphanumeric (i.e., `.' - the include file has an `#ifdef ecd.color'
in it, causing the gcc-cpp diagnostics above)

So, why does `normal' (i.e., `non-traditional' (^: ) gcc complain about these
lines??  Is this form of concatenation macro no longer valid ANSI C?  Are
non-alphanumeric characters in `#ifdef' statements also illegal?  (I note that
adding `-ansi' has no effect on the diagnostics)

	- Greg Earle
	  Sun Los Angeles Consulting
	  earle@Sun.COM
	  earle@mahendo.JPL.NASA.GOV	(Guest account)