|
From: Nicholas N. <nj...@cs...> - 2005-03-30 15:23:30
|
[oh, I forgot to send this the other day, sorry...]
On Mon, 28 Mar 2005, Jeremy Fitzhardinge wrote:
> Well, a function with 15 (or even 8) arguments is always going to be hard to
> read, and hard to write or modify (it's impossible to remember what order
> they should go in, and very easy to stuff it up by adding or deleting an
> argument - in either case you need to carefully check the call against the
> function prototype).
>
> Are you saying that the needs functions are, by definition, all-or-none
At the moment, yes.
> so that if you want to add a new function with is related but not
> essential (say, get_extra_address_info) would actually be a different
> need? Or that a tool would be always required to implement a function
> because of the all-or-none policy, even if its a nul implementation?
The latter; that's how it currently works.
There are currently 6 needs that require the tool to implement functions:
needs_tool_errors, needs_basic_block_discards, needs_command_line_options,
needs_client_requests, needs_syscall_wrapper, needs_sanity_checks.
Of these, only for sanity_checks and syscall_wrapper would it make sense
for any of the tool-supplied functions to be missing or empty. (Oh, and
maybe update_extra() for needs_tool_errors can be sensibly empty).
Also, if a tool replaces malloc, it needs to provide all those functions.
> I'm all for grouping the interface callback registrations into functionally
> related pieces, but it seems like a stretch to further assert that functional
> grouping == all-or-none.
It's not always true, but it's mostly true, and providing empty functions
doesn't seem too onerous. For example, Nulgrind has empty post_clo_init
and fini functions. I guess we could allow:
VG_(basic_tool_funcs)(NULL,
nl_instrument,
NULL)
I don't think there's a clear best answer. Grouping them as I've done
forces a tool to provide empty definitions of any optional functions,
which is not good, but prevents tools from forgetting to provide all the
necessary definitions.
N
|