From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
Subject: cu_offset vs. sect_offset field names bikeshedding [Re: [patch 2/2] typedef-checking for CU relative vs. absolute offsets]
Date: Fri, 09 Mar 2012 19:40:00 -0000 [thread overview]
Message-ID: <20120309193947.GA6256@host2.jankratochvil.net> (raw)
In-Reply-To: <87eht2n4jf.fsf@fleche.redhat.com>
Hi,
On Thu, 08 Mar 2012 22:53:08 +0100, Tom Tromey wrote:
> I think this patch is a good idea. I find that it does not clutter up
> the code very much (which was my main concern), and it adds type-safety
> to an area where we've clearly already had review and/or reasoning
> failures.
that's great, thanks for the agreement.
Now just how to call them:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Jan> typedef struct { unsigned int co; } cu_offset;
> Jan> typedef struct { unsigned int so; } sect_offset;
I find 'cu_offset' + 'sect_offset' names for the types are OK, any objective?
I do not find 'co' + 'so' great myself.
'val' + 'val' I do not find acceptable, it needs to differ, otherwise the
expressions are a mess, the type of variable is not immediately visible.
'rel_off' + 'abs_off'? It no longer matches 'cu_offset' + 'sect_offset'.
Moreover rel + abs I do not find so great, cu + sect I find better.
'rel_off' would be 7 characters, 23 lines of 143 lines of the patch would need
reindentation overflowing 80 characters.
field length | overflown lines of patch
3 3
4 7
5 13
6 15
7 23
8 27
9 31
10 35
11 41
12 45
13 47
14 47
15 49
Another proposal is 'cu_o' and 'sect_o' or even 'cu_off' or 'sect_off'.
Regards,
Jan
next prev parent reply other threads:[~2012-03-09 19:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 22:34 RFC: problem with DW_OP_GNU_deref_type and dwarf's get_base_type callback Joel Brobecker
2012-03-06 20:25 ` Tom Tromey
2012-03-06 23:46 ` Joel Brobecker
2012-03-07 17:10 ` [patch] Fix CU relative vs. absolute offsets [Re: RFC: problem with DW_OP_GNU_deref_type and dwarf's get_base_type callback] Jan Kratochvil
2012-03-07 17:13 ` [patch 2/2] typedef-checking for " Jan Kratochvil
2012-03-07 18:58 ` Doug Evans
2012-03-07 19:10 ` Jan Kratochvil
2012-03-07 19:29 ` Jan Kratochvil
2012-03-08 21:54 ` Tom Tromey
2012-03-08 21:56 ` Doug Evans
2012-03-07 19:07 ` Joel Brobecker
2012-03-07 19:16 ` Jan Kratochvil
2012-03-08 21:53 ` Tom Tromey
2012-03-09 19:40 ` Jan Kratochvil [this message]
2012-03-09 19:52 ` cu_offset vs. sect_offset field names bikeshedding [Re: [patch 2/2] typedef-checking for CU relative vs. absolute offsets] Joel Brobecker
2012-03-19 20:02 ` [commit] [patch 2/2] typedef-checking for CU relative vs. absolute offsets Jan Kratochvil
2012-03-09 19:56 ` cu_offset vs. sect_offset field names bikeshedding [Re: [patch 2/2] typedef-checking for CU relative vs. absolute offsets] Tom Tromey
2012-03-07 18:57 ` [patch] Fix CU relative vs. absolute offsets [Re: RFC: problem with DW_OP_GNU_deref_type and dwarf's get_base_type callback] Joel Brobecker
2012-03-07 19:47 ` Joel Brobecker
2012-03-08 19:40 ` [commit] " Jan Kratochvil
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=20120309193947.GA6256@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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