This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB 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] |
On May 15, 12:49pm, Andrew Cagney wrote:
> First, the return types are different. extract_address() returns > CORE_ADDR while extract_unsigned_integer returns ULONGEST. If > we were to encounter a scenario where this is a problem, it's easier > to fix a wrapper (extract_address()) instead of the myriad places in > the code which presently call extract_address(). (This point is > probably moot because I suspect we already have a lot of code which > assumes that CORE_ADDR may be interchanged with LONGEST or ULONGEST > anyway.)
sizeof(CORE_ADDR) <= sizeof(ULONGEST) so this isn't a problem.
Do we have a gdb_assert() somewhere to ensure that this is the case? (This could happen at initialization time...)
> Second, having function calls to extract_address() provides > information to the reader that you don't get by having calls to > extract_unsigned_integer(). It tells the reader that we're expecting > to get an address and not an integer. This really helps when someone > reading gdb's code is wondering about what the thing is that's being > extracted.
The extract_address function doesn't extract an address, it extracts an unsigned integer.
On the MIPS, extract_address needs to sign extend. On the d10v, extract address needs to know the address space.
Yes, I understand that. Doing the substitution you propose will make it more difficult to make the correct fix (of using extract_typed_address) at a later time.
If the code needs to extract an address it can use extract_typed_address which corectly handles all these cases.
Yes.
Is it a good thing? It eliminates a lie.
At the expense of making the code marginally less comprehensible and making it more difficult to identify the potential cases where extract_typed_address() should be used instead.
Or have all of those cases already been identified? If so, then I withdraw my objection. (Though I still like having "address" in the function name to help to document what it is that's being extracted.)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |