kobj method signature checking

Andriy Gapon avg at icyb.net.ua
Fri Mar 28 07:38:01 PDT 2008


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.

>> P.S. strangely enough for me it seems that compiler treats the following
>> two declarations differently:
>> int f();
>> and
>> int f(void);
>> The warning appears for the latter when comparing with e.g. int g(int),
>> but does not appear for the former.
> 
> This is normal for C. :(
> 


-- 
Andriy Gapon


More information about the freebsd-hackers mailing list