From: Simon Marchi <simon.marchi@ericsson.com>
To: Pedro Alves <palves@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Add comments to gdbarch_address_class_name_to_type_flags
Date: Thu, 16 Jan 2014 19:31:00 -0000 [thread overview]
Message-ID: <52D8338F.2060800@ericsson.com> (raw)
In-Reply-To: <52D82EDF.5010402@redhat.com>
On 14-01-16 02:11 PM, Pedro Alves wrote:
> On 01/16/2014 06:47 PM, Simon Marchi wrote:
>> +/* Return the appropriate type_flags for the supplied address class.
>> + This function should return 1 if the address class was recognized and
>> + type_flags was set, zero otherwise.
>
> Say true/false instead of 1/zero.
>
>> + No assumption should be made about the initial value of *type_flags_ptr,
>> + which means that if it returns 1, the function should write it, even if
>> + no flags are set. */
>
> This makes me a little confused. This is a mapping/conversion function:
>
> class name -> type flags
>
> I'd expect the function to recognize the name, and return a valid flag
> (thus return true), or not recognize the name, and return false.
>
> What would "even if no flags are set" mean? What's the use case for that?
> Recognizing a class name, but having that map to no flags? As in,
> ignoring the class name? Is that useful?
In our case, address classes are used for multiple memory spaces support. For completeness sake, I wanted to allow the user to specify that a variable is in the default address space, for those who like to be explicit. An address in the default space would cause no flag to be set. So yeah, this is a little far fetched and arguable, so probably doesn't need to be mentioned here.
The part "No assumption should be made about the initial value of *type_flags_ptr" is still important I think, so that people know that you should not just OR your flags, but overwrite the whole content.
Simon
prev parent reply other threads:[~2014-01-16 19:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 18:47 Simon Marchi
2014-01-16 19:11 ` Pedro Alves
2014-01-16 19:21 ` Sergio Durigan Junior
2014-01-16 19:26 ` Pedro Alves
2014-01-16 19:32 ` Simon Marchi
2014-01-16 19:45 ` Sergio Durigan Junior
2014-01-16 19:58 ` Pedro Alves
2014-01-16 20:12 ` Tom Tromey
2014-01-16 19:31 ` Simon Marchi [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=52D8338F.2060800@ericsson.com \
--to=simon.marchi@ericsson.com \
--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