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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
