Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 4/5] Make sect_offset and cu_offset strong typedefs  instead of structs
Date: Wed, 29 Mar 2017 15:46:00 -0000	[thread overview]
Message-ID: <ff9cee4d3eee2fbb0eb7273397ead7e1@polymtl.ca> (raw)
In-Reply-To: <1490754298-9455-5-git-send-email-palves@redhat.com>

On 2017-03-28 22:24, Pedro Alves wrote:
> A while ago, back when GDB was a C program, the sect_offset and
> cu_offset types were made structs in order to prevent incorrect mixing
> of those offsets.  Now that we require C++11, we can make them
> integers again, while keeping the safety, by exploiting "enum class".
> We can add a bit more safety, even, by defining operators that the
> types _should_ support, helping making the suspicious uses stand out
> more.
> 
> Getting at the underlying type is done with the new to_underlying
> function added by the previous patch, which also helps better spot
> where do we need to step out of the safety net.  Mostly, that's around
> parsing the DWARF, and when we print the offset for complaint/debug
> purposes.  But there are other occasional uses.
> 
> Since we have to define the sect_offset/cu_offset types in a header
> anyway, I went ahead and generalized/library-fied the idea of "offset"
> types, making it trivial to add more such types if we find a use.  See
> common/offset-type.h and the DEFINE_OFFSET_TYPE macro.
> 
> I needed a couple generaly-useful preprocessor bits (e.g., yet another
> CONCAT implementation), so I started a new common/preprocessor.h file.
> 
> I included units tests covering the "offset" types API.  These are
> mostly compile-time tests, using SFINAE to check that expressions that
> shouldn't compile (e.g., comparing unrelated offset types) really are
> invalid and would fail to compile.  This same idea appeared in my
> pending enum-flags revamp from a few months ago (though this version
> is a bit further modernized compared to what I had posted), and I plan
> on reusing the "check valid expression" bits added here in that
> series, so I went ahead and defined the CHECK_VALID_EXPR macro in its
> own header -- common/valid-expr.h.  I think that's nicer regardless.
> 
> I was borderline between calling the new types "offset" types, or
> "index" types, BTW.  I stuck with "offset" simply because that's what
> we're already calling them, mostly.

A while ago (in the pre C++ era), I asked you if we could make some 
integer types that couldn't be assigned to each other, to represent 
8-bit bytes and target bytes.  That would help avoid mixing incompatible 
lengths or offsets for targets that have 16 or 32 bit bytes, forcing us 
to do the appropriate conversion.  There was no way to do it in C.  Do 
you think offset-type could be used for that now?


  reply	other threads:[~2017-03-29 15:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29  2:25 [PATCH 0/5] dwarf2read.c: Some C++fycation Pedro Alves
2017-03-29  2:25 ` [PATCH 3/5] dwarf2read.c: Make dir_index and file_name_index strong typedefs Pedro Alves
2017-03-29 15:36   ` Simon Marchi
2017-04-04 18:54     ` Pedro Alves
2017-04-04 19:06       ` Pedro Alves
2017-03-29  2:25 ` [PATCH 2/5] gdb::optional: Add observers Pedro Alves
2017-03-29  2:25 ` [PATCH 1/5] dwarf2read.c: Some C++fycation, use std::vector, std::unique_ptr Pedro Alves
     [not found]   ` <ef286ec115c7c1986e41dd08ecf14fcf@polymtl.ca>
2017-04-04 18:57     ` Pedro Alves
2017-03-29  2:25 ` [PATCH 5/5] dwarf2read.c: C++fy lnp_state_machine Pedro Alves
2017-03-29  2:32 ` [PATCH 4/5] Make sect_offset and cu_offset strong typedefs instead of structs Pedro Alves
2017-03-29 15:46   ` Simon Marchi [this message]
2017-04-05 15:13     ` Pedro Alves

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=ff9cee4d3eee2fbb0eb7273397ead7e1@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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