public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@physics.uc.edu> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: preprocessor/5234: Variable arguments list in macro fail with another macro inclusion Date: Tue, 01 Jan 2002 10:56:00 -0000 [thread overview] Message-ID: <20020101185601.2446.qmail@sources.redhat.com> (raw) The following reply was made to PR preprocessor/5234; it has been noted by GNATS. From: Andrew Pinski <pinskia@physics.uc.edu> To: david.taillandier@domainename.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: preprocessor/5234: Variable arguments list in macro fail with another macro inclusion Date: Tue, 1 Jan 2002 13:51:03 -0500 This has been fixed in gcc 3.0.3 and gcc 3.1 Thanks, Andrew Pinski PS here is what I get when I run the preprocessor on the source (with the include removed): # 1 "myc.c" # 1 "<built-in>" # 1 "<command line>" # 1 "myc.c" # 9 "myc.c" int main( void ) { printf( "123" "ending string\n" ); printf( "456" "ending string\n" ); printf( "789" ); return 0; } On Tuesday, January 1, 2002, at 01:36 , david.taillandier@domainename.com wrote: > >> Number: 5234 >> Category: preprocessor >> Synopsis: Variable arguments list in macro fail with another >> macro inclusion >> Confidential: no >> Severity: non-critical >> Priority: medium >> Responsible: unassigned >> State: open >> Class: rejects-legal >> Submitter-Id: net >> Arrival-Date: Tue Jan 01 10:46:01 PST 2002 >> Closed-Date: >> Last-Modified: >> Originator: David TAILLANDIER >> Release: gcc version 2.95.3 20010315/djgpp (release) >> Organization: >> Environment: > Win95 / MS-DOS 6 / Win98 >> Description: > In one case, clearly identified, when using variable > arguments list macro with another macro inside the first > one, the preprocessing process (duh) gives an error. > See sample, it's very simple. > > Hope I don't miss something. > david.taillandier@domainename.com >> How-To-Repeat: > > #include <stdio.h> > > #define _(text_to_translate) text_to_translate > > #define PROBLEM_HERE( text, vargs... ) printf( text > _("ending string\n"), ## vargs ) > #define NO_PROBLEM_HERE( text, vargs... ) printf( text > _("ending string\n") , ## vargs ) > #define NOR_HERE( text, vargs... ) printf( text, ## > vargs ) > > /* the only difference is the space before the comma witch is not > present in PROBLEM_HERE */ > > int > main( void ) > { > PROBLEM_HERE( "123" ); > NO_PROBLEM_HERE( "456" ); > NOR_HERE( "789" ); > > return 0; > } >> Fix: > I don't know how to fix this, sorry. > But a workaround is to add a space before the comma > preceding the ## >> Release-Note: >> Audit-Trail: >> Unformatted: > >
next reply other threads:[~2002-01-01 18:56 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-01-01 10:56 Andrew Pinski [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-01-01 11:42 rodrigc 2002-01-01 11:16 Zack Weinberg 2002-01-01 10:46 david.taillandier
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=20020101185601.2446.qmail@sources.redhat.com \ --to=pinskia@physics.uc.edu \ --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).