Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <8F23E55D511AD5119A6800D0B76FDDE1CA2F85@cpex3.channelpoint.com>
From: Troy Noble <troy DOT noble AT channelpoint DOT com>
To: "'Anyos DOT Bela AT evosoft DOT hu'" <Anyos DOT Bela AT evosoft DOT hu>, cygwin AT cygwin DOT com
Subject: RE: 1.3.2: gcc bug (NT 4.0)
Date: Fri, 27 Jul 2001 08:18:51 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

What you are trying to do is somewhat fraught with peril anyway.
For example, even if the space weren't inserted when your macro
gets expanded... the resulting line of code:

     printf( "%s", /usr/X11R6/lib );

isn't going to compile anyway.

But for what it's worth... I tried that same code on a linux
machine with egcs egcs-2.91.66 and I get the same results.
So you might want to bring this same question up on a gcc-specific
list somewhere since it seems to be present in multiple versions
of gcc's preprocessor and across platforms.  It's not specific
to cygwin in other words.

Out of curiosity... I tried it with Visual C++ 6.0 and it does
exhibit the right behavior.  So this may be a legitimate gcc
bug that the gcc maintainers need to know about nonetheless.

#line 1 "tmp.c"


int main( int argc, char *argv[] )
{
        printf( "%s", /usr/X11R6/lib );
        return 0;
}


By the way, you can change your code as follows to work around
the bug and produce a working program with gcc as well.  The reason
this works is that ANSI-C compilers turn consecutive
whitespace-separated string literals into a single string
literal:

.../tmp$ cat tmp.c
#define Glue(a,b) a ##b

#define TestDef "/usr/X11R6"

int main( int argc, char *argv[] )
{
      printf( "%s", Glue(TestDef,"/lib") );
      return 0;
}

.../tmp$ gcc -E tmp.c
# 1 "tmp.c"


int main( int argc, char *argv[] )
{
      printf( "%s\n",  "/usr/X11R6" "/lib"   );
      return 0;
}

.../tmp$ gcc tmp.c
.../tmp$ ./a.out
/usr/X11R6/lib

Troy

-----Original Message-----
From: Anyos Bela [mailto:Anyos DOT Bela AT evosoft DOT hu]
Sent: Friday, July 27, 2001 7:48 AM
To: cygwin AT cygwin DOT com
Subject: 1.3.2: gcc bug (NT 4.0)


Hi Guys,

I think I found a problem in connection with
gcc 'token-pasting' operator (##)

	$ gcc -v
	Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
	gcc version 2.95.3-5 (cygwin special)

I use cygwin v1.3.2 under NT 4.0 Service Pack 6.

Here's a little example to show its failure:
( obviously it has no meaning, I used it just for demonstrating the
problem )

--------------------
#define Glue(a,b) a##b

#define TestDef /usr/X11R6

int main( int argc, char *argv[] )
{
	printf( "%s", Glue( TestDef,/lib ) );
	return 0;
}
---------------------

Feeding this to gcc it produces the following on my computer:

---------------------
$ gcc -E test.c
# 1 "test.c"


int main( int argc, char *argv[] )
{
        printf( "%s",   /usr/X11R6 /lib    );
        return 0;
}
---------------------

Please notice the gap between '/usr/X11R6' and '/lib'.
It only happens if the first paramter of the 'Glue' macro is
another macro. If I use a literal it works fine!
I also tested it on Linux and it worked fine there.


Thanks for your help and best regards,
Bela

ps.: Can you please cc answers to me, because I'm not on the list, yet !
     Thanks !


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/