public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: 'Zack Weinberg' <zack@codesourcery.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: preprocessor/4923: Concatenation appears to handle whitespace incorrectly Date: Mon, 19 Nov 2001 20:27:00 -0000 [thread overview] Message-ID: <20011123185600.21004.qmail@sourceware.cygnus.com> (raw) The following reply was made to PR preprocessor/4923; it has been noted by GNATS. From: 'Zack Weinberg' <zack@codesourcery.com> To: "Baum, Nathan I" <s0009525@chelt.ac.uk> Cc: gcc-gnats@gcc.gnu.org Subject: Re: preprocessor/4923: Concatenation appears to handle whitespace incorrectly Date: Fri, 23 Nov 2001 10:51:01 -0800 On Thu, Nov 22, 2001 at 01:47:51PM -0000, Baum, Nathan I wrote: > > > At that point the tokens on either side of ## are ")" and "def". > > Pasting them together produces an invalid token, > > ")def", which triggers undefined behavior - we choose to pretend the > > ## never happened. Then "FOO ( abc )" gets expanded to produce "abc". > > Since "abc" and "def" were not concatenated, cpp has to put a space > > between them so they are interpreted sa separate tokens. > > Would it break existing programs if ## were to concatenate the two tokens > regardless (in some later version of gcc)? I'd imagine that no sensible > program would rely upon undefined behaviour, so it shouldn't. Presumeably, > it'd have to throw the two tokens away and rescan the newly created string, > but that doesn't _seem_ like a major problem (I don't know how CPP handles > these things internally, so it might be). It does, in fact, concatenate "the two tokens" in the textual output - but the two tokens which get concatenated are ")" and "def". Contrast #define a(x) FOO(abc) ## x #define b(x) FOO(abc) x a(def) -> FOO(abc)def b(def) -> FOO(abc) def To do what you apparently want, when the ")" was the last character of a macro invocation, it would have to remember that it had been pasted after and apply the paste to the last token of the macro expansion. This would be a lot of work and frankly I don't see the point. Show me real code that desperately needs this functionality and I'll show you how to fix it so it's standard conforming C. > > gcc 3.x will warn you when this happens: > > test.c:5:1: warning: pasting ")" and "def" does not give a valid > preprocessing token > > Hmm. Shouldn't the message say 'concatenating' rather than 'pasting'? The manual uses the two terms interchangeably, and I think the error message is already long enough. zw
next reply other threads:[~2001-11-23 18:56 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-11-19 20:27 'Zack Weinberg' [this message] -- strict thread matches above, loose matches on Subject: below -- 2001-11-19 20:36 'Zack Weinberg' 2001-11-19 20:32 Baum, Nathan I 2001-11-18 16:50 Baum, Nathan I 2001-11-17 0:46 rodrigc 2001-11-17 0:44 rodrigc 2001-11-16 23:56 Zack Weinberg 2001-11-16 23:46 s0009525
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20011123185600.21004.qmail@sourceware.cygnus.com \ --to=zack@codesourcery.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).