New code!
Magicfilter has been pushed up to version 2.3.c, to deal with Yet Another Feature in modern commercial Linuxes.
I used to use token pasting (an experimental ANSI thing from the 1980s, published in a little-read document titled ANSI/ISO 9899-1989, Programming Languages - C) as part of the lprng debogification code. The code was pretty simple
#ifdef HAVE_UNSETENV # define UNSET(x) unsetenv(x) #else # define UNSET(x) putenv(x ## "=") #endif
and I foolishly thought that since it was in the ANSI C89 standard that it would be portable.
No. Tim Johnston sent me a bug report against magicfilter, along with a log of a failed make, and that log was full of error messages like
args.c:117:19: pasting ""LPUSER"" and ""="" does not give a valid preprocessing token args.c:118:19: pasting ""LPHOST"" and ""="" does not give a valid preprocessing token args.c:119:21: pasting ""LPINDENT"" and ""="" does not give a valid preprocessing token args.c:120:20: pasting ""LPCLASS"" and ""="" does not give a valid preprocessing token args.c:121:21: pasting ""LPFORMAT"" and ""="" does not give a valid preprocessing token args.c:122:18: pasting ""LPJOB"" and ""="" does not give a valid preprocessing token args.c:123:21: pasting ""LPCOPIES"" and ""="" does not give a valid preprocessing token args.c:124:23: pasting ""BANNERNAME"" and ""="" does not give a valid preprocessing token args.c:125:20: pasting ""PRINTER"" and ""="" does not give a valid preprocessing token args.c:126:20: pasting ""LPQUEUE"" and ""="" does not give a valid preprocessing token args.c:127:19: pasting ""LPACCT"" and ""="" does not give a valid preprocessing token
Now this is a new one on me (and not just me; a quick websearch on does not give a valid preprocessing token brings up scads of results, all of which say something like "I upgraded (Linux|gcc) to the latest version, and it broke!"), but it's apparently not a bug in gcc. No, it's a deliberately broken part of gcc, much like the way they deliberately broke i386 asm() directives after gcc 2.7.
So. Since it's deliberately broken, I can't use ANSI preprocessor features in magicfilter anymore. (Either that or I need to modify configure.sh so that it will refuse to work when it finds a machine with a broken gcc. And since all of the free Un*xes out there slavishly slurp up the latest broken crapware from the FSF, configure.sh not working on a machine with a broken gcc means it won't work anywhere. Which is not exactly the most satisfying outcome.) Thus, new code! to deal with broken systems software. Again.
Comments
Well, perhaps it is for C99 (which is not C), but K&R 2 (the only Ansi spec I’ve seen online is one of the preliminary C99 specs that shows as an example of ## a case where two strings are concatenated together) says “The preprocessor operator ## provides a way to concatenate actual arguments during macro expansion” and gives, as an example, a case where ## is used (pg91) to paste two regular old tokens together to form another token. (on pg230, K&R look at ## again and immediately flee, shrieking in terror.)
And what is a string aside from a token? A redefinition of C where ## concatenates two tokens together except when those tokens are strings is, um, almost perlish in its arrogant redefinition of terms, and is thus unworthy of being called C.
Comments are closed
I realize that this is a very old post, so you have probably figured it out in the meantime, but the reason “##” stopped working is not because something is being “broken” in gcc, but because “##” is not the correct way to combine string constants in ANSI/ISO C and gcc was fixed to report that as it is required to. Just delete the “##” and it will work (“abc” “def” is the same as “abcdef” in C), seriously.