Re: kobj method signature checking

on 28/03/2008 16:37 Andriy Gapon said the following:
on 27/03/2008 20:08 John Baldwin said the following:
On Thursday 27 March 2008 12:45:38 pm Andriy Gapon wrote:
on 01/03/2008 10:49 Andriy Gapon said the following:
Here's one strange thing - in your patch you accidentally have
parameters of device_identify switched, I initially inherited that bug
too. I got no error/warning from compiler whatsoever. It wasn't until I
saw that device_get_unit(parent) returned garbage that I my untrained
eye noticed the mistake.
As this thread died off I just want to make sure that the above issue is
not lost.
Maybe we should modify KOBJMETHOD(NAME, FUNC) macro to somehow check
FUNC signature/type against the expected signature/type (which is
available as NAME##_t)?
It would be nice if we could do that, yes.

Maybe something like the following (a bit ugly but I couldn't think of
anything better and syntactically correct):
{ &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) }

This is supposed to produce the following warning if FUNC and NAME##_t
have different types:
warning: comparison of distinct pointer types lacks a cast

The message is also not very descriptive.
A compile warning/error would be nice though.

Then the proposed code should be good enough.
That is:
#define KOBJMETHOD(NAME, FUNC) \
{ &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) }

BTW, the expression is an obvious NOP and I think that the compiler is
required to calculate constant initializer expressions at compile time,
so binary wise there should not be any incompatibilities too.

And the demonstration of the code in work – the following is from 6.3
RELEASE kernel build (plus the above change):
/usr/src/sys/dev/acpica/acpi_pcib_acpi.c:109: warning: comparison of
distinct pointer types lacks a cast
/usr/src/sys/dev/acpica/acpi_pcib_acpi.c:110: warning: comparison of
distinct pointer types lacks a cast
*** Error code 1

This is because pcib_read_config_t is defined to have several parameters
of "u_int" type and acpi_pcib_read_config has "int" for them.
Ditto for acpi_pcib_write_config and pcib_write_config_t.

--
Andriy Gapon
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Fast numerical functions
    ... rif wrote: ... (defun foo (x y) ... This clearly feels like a 'sufficiently smart compiler could figure ... version of func, which uses generic arithmetic. ...
    (comp.lang.lisp)
  • Re: A problem initializing a static char array
    ... with the VxWorks 5.4 C compiler (which I believe is Wind ... result (run on a x86 machine running VxWorks 5.4): ... You haven't shown us a complete program, or even a call to func(). ...
    (comp.lang.c)
  • Re: allocating space for local variables
    ... int arr2; ... true or the space is allocated when the function "func" is called. ... The answer would be compiler dependant, compiler flags dependant, and ...
    (comp.lang.c)
  • Re: allocating space for local variables
    ... int arr2; ... true or the space is allocated when the function "func" is called. ... The answer would be compiler dependant, compiler flags dependant, and ...
    (comp.lang.c)