This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Fwd: Re: Problem compiling fdutils 5.4


Hi,

I think it could be interesting for you to look at this problem we had.

--
Pierre.








On 2001.09.29 08:03 Alain Knaff wrote:
>Hi,
>
>I try to compile fdutils 5.4 on my linux slackware 8 with gcc-3.0.1
>there was no problem with the configure, but for the make i got this :
>
>root@pierre:/tmp/fdutils-5.4# gmake
>gmake -C src all
>gmake[1]: Entering directory `/tmp/fdutils-5.4/src'
>gcc -Wall -g -O2 -I. -I.  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\"  -c 
>-o
>floppycontrol.o floppycontrol.c
>floppycontrol.c:388:1: directives may not be used inside a macro argument
>floppycontrol.c:388:1: unterminated argument list invoking macro "printf"
>floppycontrol.c: In function `main':
>floppycontrol.c:389: parse error before "drivstat"
>gmake[1]: *** [floppycontrol.o] Error 1
>gmake[1]: Leaving directory `/tmp/fdutils-5.4/src'
>gmake: *** [compile] Error 2

It looks to me like a gcc3 issue. Printf has always been a function,
rather than a (preprocessor) macro, and lots of code, not just
fdutils, assumes it is still function. IMHO, this change is a rather
aggressive one, and should be fixed in gcc3

Macros behave differently than functions in the following areas, which
are used commonly in all kinds of applications:

- functions calls can spread over several lines, whereas macro calls
can't. Apparently, they've found a way to solve this.
- macros interact in rather interesting ways with variable
post-incrementation/decrementation (var incremented/decremented each
time the macro references it, rather than one time when the function
is called). May not be a problem if printf only references its
parameters once.
- and, most importantly: as macros are preprocessor instructions, you
cannot nest other preprocessor constructs (such as #ifdef) inside.

floppycontrol has the following construct, which probably causes
problems:


		printf("%s %s %s %s %s\n", 
		       drivstat.flags & FD_VERIFY ? "verify" : "",
		       drivstat.flags & FD_DISK_NEWCHANGE ? "newchange" : "",
		       drivstat.flags & FD_NEED_TWADDLE ? "need_twaddle" : "",
#ifdef FD_DISK_CHANGED
		       drivstat.flags & FD_DISK_CHANGED ? "disk_changed" : "",
#endif
		       drivstat.flags & FD_DISK_WRITABLE ?"disk_writable" : "");


As a workaround, you can fix this manually.

- if your system has FD_DISK_CHANGED defined (in fd.h), replace it
with the following:

		printf("%s %s %s %s %s\n", 
		       drivstat.flags & FD_VERIFY ? "verify" : "",
		       drivstat.flags & FD_DISK_NEWCHANGE ? "newchange" : "",
		       drivstat.flags & FD_NEED_TWADDLE ? "need_twaddle" : "",
		       drivstat.flags & FD_DISK_CHANGED ? "disk_changed" : "",
		       drivstat.flags & FD_DISK_WRITABLE ?"disk_writable" : "");

- and if you don't have FD_DISK_CHANGED, use the following:

		printf("%s %s %s %s %s\n", 
		       drivstat.flags & FD_VERIFY ? "verify" : "",
		       drivstat.flags & FD_DISK_NEWCHANGE ? "newchange" : "",
		       drivstat.flags & FD_NEED_TWADDLE ? "need_twaddle" : "",
		       drivstat.flags & FD_DISK_WRITABLE ?"disk_writable" : "");


In any case, please also notify the gcc people about this issue. Ansi
standards specify that printf should be a function, not a macro, and
as this example shows, both constructs do _not_ behave the same way.

Regards,

Alain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]