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 Thu, Aug 23, 2018 at 5:13 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 08/23/2018 08:07 AM, Michael Matz wrote:
> > Hi,
> >
> > On Thu, 23 Aug 2018, Richard Biener wrote:
> >
> >>>> 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 ...
> >
> > No, you can't write a string literal which is not zero terminated, because
> > in translation phase 7 a zero code is appended to all character sequences
> > resulting from string literals, which is then used to allocate and
> > initialize a static (wide) character array of just the right size,
> > including the zero code.
> >
> > The above construct uses that static char[3] array from the string literal
> > to initialize a char[2] array (which is explicitely allowed), and _that_
> > one is not zero terminated.  But it's also no string literal.
>
> Yes, you're right.  I misinterpreted Richard's question as
> asking if one could construct an unterminated array of chars
> using a string literal.
>
> The distinction that I thought would be useful to capture in
> Gimple is between "12" that initializes an array of two elements
> (and where the nul doesn't fit) vs "12" that initializes one of
> three elements (and where the nul does fit).  It's probably not
> terribly important when the array type also appears in Gimple
> like in the case above but there are (perhaps corner) cases
> where it doesn't, as in the second one below:
>
>    char a[2] = "12";
>    char *p = (char[2]){ "12" };
>
> which ends up represented as:
>
>    char a[2];
>    char * p;
>    char D.1910[2];
>
>    try
>      {
>        a = "12";
>        D.1910 = "12";
>        p = &D.1910;
>      }

Yeah, we currently require useless_type_conversion_p between the
LHS type and the RHS type (type of a vs. type of "12") which implies
TYPE_SIZE matches (if constant).  That means GIMPLE expects
at least the type of "12" to not include the NUL.

Richard.

> Martin


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