On Wed, 2012-11-28 at 17:31 +0100, Jan Kratochvil wrote:
Application should be able to write its own parser
and this is just one its instance (it could not anyway but that is a different
patch "[patch 3/4] unwinder: Provide dwfl_core_filename_report").
Yeah. You are a few steps ahead of me.
But in practice if you used dwfl_standard_argp then an application
had to give
up using USERDATA and there was no other field for the application left, as
application cannot modify dwfl_standard_argp to share the USERDATA field some
way, so an application would have to copy+modify / reimplement
dwfl_standard_argp. Which is not great just to save a Dwfl_Module field.
So in the end it is just an dwfl_standard_argp () implementation detail.
OK, I cannot think of a better way than using some internal libwfl
field. And if we do think of something better we now have testcases.
Still one suggestion. There can be only one executable for a core based
Dwfl, can't there? So if we are using libdwfl internals anyway it seems
better to store the state in the Dwfl struct instead of reserving a
field in each Dwfl_Module struct.
And one nit. The libdwfl/ChangeLog has a line that is way too long.