This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] print full STRING_CST in Gimple dumps (PR 87052)


On Wed, Aug 22, 2018 at 5:05 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 08/22/2018 06:48 AM, Richard Biener wrote:
> > On Wed, Aug 22, 2018 at 4:56 AM Martin Sebor <msebor@gmail.com> wrote:
> >>
> >> In the discussion of the fallout from the enhancement for pr71625
> >> it was pointed out that STRING_CSts in Gimple dumps extend only
> >> to the first nul and don't include any subsequent characters,
> >> and that this makes the dumps harder to read and might give rise
> >> to the question whether the code is correct.
> >>
> >> In the attached patch I enhance the pretty_print_string() function
> >> to print the full contents of a STRING_CST, including any embedded
> >> nuls to make the dumps clearer.  I got rid of the single digit
> >> escapes like '\1' since they make the string look ambiguous.
> >> If TREE_STRING_LENGTH (node) is guaranteed to be non-zero these
> >> days the test for it being so may be redundant but I figured it's
> >> better to be safe than sorry.
> >>
> >> A further enhancement might be to also distinguish the type of
> >> the STRING_CST.
> >
> > And somehow indicate whether it is \0 terminated (just thinking of
> > the GIMPLE FE and how it parses string literals simply by relying
> > on libcpp).
> >
> > Can you write a not \0 terminated string literal in C?
>
> Yes: char a[2] = "12";

I thought they are fully defined in translation phase #1 ...

> I briefly considered making the terminating nul visible when
> there was one but there's at least one test that scans GIMPLE
> for the expected string and it failed so I didn't pursue this
> idea further.

Yes, I think it would just confuse people at the moment.  I thought
of somehow marking non-terminated literals, like  "12"[nt] or so ...
or by using an alternate quote "12' (eh).

Anyway, not too important I guess if you for a moment exclude
the -fdump-XXX-gimple and re-parsing with the GIMPLE FE case.

Richard.

> The tests can certainly be changed to look for the new pattern
> if we should decide to make a change here.  I'm not sure what
> would be best.  Printing "12\x00" for an ordinary nul-terminated
> literal looks like there might be an extra nul after the first
> one.  Leaving it out doesn't distinguish it from the unterminated
> array.  Using the braced-list notation (i.e.,  a = { '1', '2' }
> for unterminated arrays doesn't capture the fact that it's
> represented as STRING_CST).
>
> I'm open to suggestions.
>
> Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]