Will be speaking about KDevelop at LinuxCon Japan 2012

[Alexandre Courbot]

> Ah I thought you are talking about function pointers in general, which afaik
> are not properly parsed/interpreted by our cpp lang code yet.

The parser does not raise any error, but the DUchain seems messed up
indeed (e.g. pointing at a function pointer declared as a member of a
struct will reference the struct).

>> Basically I need to
>> detect where function pointers declarations are receiving a value,
>> check if that value is constant, and record it somewhere to display it
>> in the popup window.
>
> This sounds... "special" - could you explain (maybe with some short code
> examples) of what you actually want to know where? Generally I doubt this kind
> of information is tracked by us yet.

It is a way to support "virtual functions" in C, which the kernel
extensively uses to implement its abstractions. For instance, power
management for a device is implemented through a struct that acts as a
virtual function table:

struct dev_pm_ops {
	int (*suspend)(struct device *dev);
	int (*resume)(struct device *dev);
}

A device driver can then include a pointer to this struct:

struct device_driver {
	const struct dev_pm_ops *pm;
}

That way, device-independant code can call the device-specific suspend
method like this:

	driver->pm->suspend(device);

Which is equivalent to having a "driver" class with "suspend" and
"resume" virtual functions. And just as KDevelop is capable is
tracking overloaded virtual functions, I'd like to support the same
for these function pointers. That is, as the parser notices a
statement like that:

	driver->pm->suspend = &foo_suspend;

or

struct device_driver bar_driver = {
	.pm = {
		.suspend = &bar_suspend,
	},
};

I'd like to be able to present references to foo_suspend and
bar_suspend every time the user points a call to the suspend member of
dev_pm_ops.

That would be a real game-changer for kernel development. The kernel
is *thousands* of drivers or architecture-specific functions used the
same way, but most of the time only a few (and often only one) are
used in a given configuration. Since kdev-kernel tunes the parser to
only work on what is needed for the user's kernel configuration, it is
only parsing the assignments that may be made at runtime. I can't
stress enough how many hours are spent looking for where the hell
could this stupid function pointer point to. With such a feature,
navigating the kernel would be as easy as navigating C++ code with
virtual functions.

I don't see why this would not be possible, but it requires some work
- starting with proper function pointer support. Do you think I can
realisticly get that done within a month?

Unrelated, but it also appears more and more that I should also
separate the C-specific behavior from the C++ parser (i.e. "class" or
"virtual" are valid identifiers in C). If this freaks some people out,
I could stick that to the yet-to-be "C specific" part of the parser
(alongside with the designated initializers which are not valid in
C++).

Alex.