Bug 22042 - [3.4/4.0/4.1 Regression] stringification BUG
Summary: [3.4/4.0/4.1 Regression] stringification BUG
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.3
Assignee: Andrew Pinski
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: patch, wrong-code
Depends on:
Blocks: 16989 16620
  Show dependency treegraph
 
Reported: 2005-06-13 05:27 UTC by s.nakayama
Modified: 2005-11-04 00:28 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 2.95.3
Known to fail: 3.0.4 3.2.3 3.3.3 3.3.6 3.4.4 4.0.0
Last reconfirmed: 2005-10-17 23:02:10


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description s.nakayama 2005-06-13 05:27:44 UTC
// test code
#define S(X) S2(X)
#define S2(X) #X
#define TAB "	" /* 0x09 */

S(S(TAB))


// gcc -E -P OUTPUT

"\"\\\"\\011\\\"\""

// expected result

"\"\\\"	\\\"\""


GCC # preprocessing operator converts the non-printable characters to octal.
But this behavior is non standard.
Comment 1 Andrew Pinski 2005-06-13 12:36:13 UTC
I don't see why this is really a bug because if you output the string, it will look the same.
Comment 2 s.nakayama 2005-06-14 07:20:32 UTC
(In reply to comment #1)
Hmm, it does't look the same.

// test code
#define S(X) S2(X)
#define S2(X) #X
#define TAB "	" /* 0x09 */

main()
{
  puts(S(S(TAB)));
}

// GCC 4.0.0 result
"\"\011\""

// GCC 2.95.3 result(expected result)
"\"	\""

Comment 3 s.nakayama 2005-06-23 15:35:18 UTC
(In reply to comment #1)
> I don't see why this is really a bug because if you output the string, it 
will look the same.

NO! Your guess is wrong.
I never report, if the output always looks the same.
I wrote the sample if you output the string, it do not look the same.

Comment 4 Andrew Pinski 2005-07-09 16:29:59 UTC
Huh? I cannot reproduce it at all.
with all of the versions of GCC I tried from 2.95.3 to 4.1.0 I get the following:
"\"\\\"   \\\"\""
Comment 5 s.nakayama 2005-07-09 18:23:09 UTC
(In reply to comment #4)
> Huh? I cannot reproduce it at all.
> with all of the versions of GCC I tried from 2.95.3 to 4.1.0 I get the 
following:
> "\"\\\"   \\\"\""

Did you confirm there was a tab in the string?
I consider that your code is the tab has been converted into space.
If there is a tab in the string,
try the string including other suitable non-printable character.
Comment 6 Andrew Pinski 2005-07-09 18:32:44 UTC
The relevant part of the standard (C99: 6.10.3.2P2)
Otherwise, the original spelling of each preprocessing token in the argument is retained in the 
character string literal, except for special handling for producing the spelling of string literals and 
character constants: a\character is inserted before each" and \character of a character constant or 
string literal (including the delimiting " characters), except that it is implementation-defined whether 
a\character is inserted before the\character beginning a universal character name. If the replacement 
that results is not a valid character string literal, the behavior is undefined. The character string literal 
corresponding to an empty argument is ""
Comment 7 Andrew Pinski 2005-07-22 21:13:43 UTC
Moving to 4.0.2 pre Mark.
Comment 8 Steven Bosscher 2005-10-17 09:29:07 UTC
What is the deal here?  Is there a bug, or not?  If so, can someone
confirm the bug, and otherwise close it as invalid?
Comment 9 Andrew Pinski 2005-10-17 23:02:09 UTC
Confirmed a bug by Neil Booth on IRC.  This sounds like this was added by Zack too.
Comment 10 Andrew Pinski 2005-10-18 23:39:21 UTC
I have a fix for the preprocessor which I need to test.
Comment 11 Andrew Pinski 2005-10-22 21:53:14 UTC
Sorry but my machine went bonkers and I cannot submit this.
Comment 12 Andrew Pinski 2005-10-27 14:33:37 UTC
I will relook at this and post it soon.
Comment 13 Andrew Pinski 2005-10-27 19:36:55 UTC
Patch submitted: <http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01583.html>.
Comment 14 Mark Mitchell 2005-10-31 03:46:11 UTC
Leaving as P2.
Comment 15 Mark Mitchell 2005-11-03 23:49:37 UTC
Joseph, you're probably the person who best understands the behavior required by the standard.  

Since Per writes:

"I don't know enough about fine points of the standard to say what is
right.  If you and Andrew think it is right, I'm ok with it."

would you mind reviewing the patch?  Andrew, if Joseph approves the patch, it is OK. 
Comment 16 joseph@codesourcery.com 2005-11-04 00:05:38 UTC
Subject: Re:  [3.4/4.0/4.1 Regression] stringification
 BUG

On Thu, 3 Nov 2005, mmitchel at gcc dot gnu dot org wrote:

> Joseph, you're probably the person who best understands the behavior required
> by the standard.  
> 
> Since Per writes:
> 
> "I don't know enough about fine points of the standard to say what is
> right.  If you and Andrew think it is right, I'm ok with it."
> 
> would you mind reviewing the patch?  Andrew, if Joseph approves the patch, it
> is OK. 

Except for some laxity in the handling of UCNs (for C but not for C++) the 
standards exactly define how the spelling of a token translates into the 
spelling of the result of applying # to it, and there is nothing to allow 
the conversion to octal; this patch is correct.

Comment 17 Andrew Pinski 2005-11-04 00:23:06 UTC
Subject: Bug 22042

Author: pinskia
Date: Fri Nov  4 00:23:01 2005
New Revision: 106463

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106463
Log:
2005-11-03  Andrew Pinski  <pinskia@physics.uc.edu>

        PR preprocessor/22042
        * macro.c (_cpp_builtin_macro_text): Lower the needed max
        buffer size.
        (cpp_quote_string): Don't octalify non printable
        charactors.
2005-11-03  Andrew Pinski  <pinskia@physics.uc.edu>

        PR preprocessor/22042
        * gcc.dg/cpp/strify4.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/cpp/strify4.c
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/macro.c

Comment 18 Andrew Pinski 2005-11-04 00:28:36 UTC
Fixed in 4.0.3.
Comment 19 Andrew Pinski 2005-11-04 00:28:51 UTC
Subject: Bug 22042

Author: pinskia
Date: Fri Nov  4 00:28:39 2005
New Revision: 106465

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106465
Log:
2005-11-03  Andrew Pinski  <pinskia@physics.uc.edu>

        PR preprocessor/22042
        * macro.c (_cpp_builtin_macro_text): Lower the needed max
        buffer size.
        (cpp_quote_string): Don't octalify non printable
        charactors.
2005-11-03  Andrew Pinski  <pinskia@physics.uc.edu>

        PR preprocessor/22042
        * gcc.dg/cpp/strify4.c: New test.


Added:
    branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/cpp/strify4.c
      - copied unchanged from r106463, trunk/gcc/testsuite/gcc.dg/cpp/strify4.c
Modified:
    branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_0-branch/libcpp/ChangeLog
    branches/gcc-4_0-branch/libcpp/macro.c