public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: Lewis Hyatt <lhyatt@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: GTY: Explicitly reject 'string_length' option for (fields in) global variables (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)
Date: Wed, 5 Jul 2023 10:13:44 +0200	[thread overview]
Message-ID: <CAFiYyc1yrW8PQx1LoU9q=1wfXhFk1LFrF3qAv1vzZRAVo-c6hg@mail.gmail.com> (raw)
In-Reply-To: <87bkgqvlst.fsf@euler.schwinge.homeip.net>

On Wed, Jul 5, 2023 at 9:51 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> > [...] add a new
> > GTY option "string_length" so that gt_pch_note_object can be informed the
> > actual length it ought to use, [...]
>
> > --- a/gcc/doc/gty.texi
> > +++ b/gcc/doc/gty.texi
> > @@ -196,7 +196,26 @@ static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
> >  Note that the @code{length} option is only meant for use with arrays of
> >  non-atomic objects, that is, objects that contain pointers pointing to
> >  other GTY-managed objects.  For other GC-allocated arrays and strings
> > -you should use @code{atomic}.
> > +you should use @code{atomic} or @code{string_length}.
> > +
> > +@findex string_length
> > +@item string_length ("@var{expression}")
> > +
> > +In order to simplify production of PCH, a structure member that is a plain
> > +array of bytes (an optionally @code{const} and/or @code{unsigned} @code{char
> > +*}) is treated specially by the infrastructure. Even if such an array has not
> > +been allocated in GC-controlled memory, it will still be written properly into
> > +a PCH.  The machinery responsible for this needs to know the length of the
> > +data; by default, the length is determined by calling @code{strlen} on the
> > +pointer.  The @code{string_length} option specifies an alternate way to
> > +determine the length, such as by inspecting another struct member:
> > +
> > +@smallexample
> > +struct GTY(()) non_terminated_string @{
> > +  size_t sz;
> > +  const char * GTY((string_length ("%h.sz"))) data;
> > +@};
> > +@end smallexample
>
> In preparation for another thing I'm working on, OK to push the attached
> "GTY: Explicitly reject 'string_length' option for (fields in) global variables"
> (with <https://inbox.sourceware.org/[TODO]> pointing to this message)?

OK

>
> Grüße
>  Thomas
>
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

      reply	other threads:[~2023-07-05  8:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 22:14 [PATCH] pch: Fix streaming of strings with embedded null bytes Lewis Hyatt
2022-10-19 11:54 ` Richard Sandiford
2022-10-19 12:08   ` Jakub Jelinek
2022-10-19 12:17     ` Richard Sandiford
2022-10-19 12:23       ` Jakub Jelinek
2022-10-19 12:47         ` Lewis Hyatt
2023-07-04 15:50 ` 'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes) Thomas Schwinge
2023-07-04 19:56   ` Lewis Hyatt
2023-07-05  7:56     ` GTY: Enhance 'string_length' option documentation (was: 'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)) Thomas Schwinge
2023-07-05  8:15       ` Richard Biener
2023-07-05  7:50 ` GTY: Explicitly reject 'string_length' option for (fields in) global variables (was: [PATCH] pch: Fix streaming of strings with embedded null bytes) Thomas Schwinge
2023-07-05  8:13   ` Richard Biener [this message]

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='CAFiYyc1yrW8PQx1LoU9q=1wfXhFk1LFrF3qAv1vzZRAVo-c6hg@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lhyatt@gmail.com \
    --cc=thomas@codesourcery.com \
    /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: link
Be 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).