From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 15:07:34 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A191065671; Fri, 28 Mar 2008 15:07:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id AC6DF8FC18; Fri, 28 Mar 2008 15:07:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 887A0744026; Fri, 28 Mar 2008 17:07:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZtdDlDsjqA8; Fri, 28 Mar 2008 17:07:32 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 19B1A43C725; Fri, 28 Mar 2008 17:07:32 +0200 (EET) Message-ID: <47ED09B3.9010309@icyb.net.ua> Date: Fri, 28 Mar 2008 17:07:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <47C918B7.9040504@icyb.net.ua> <47EBCF32.9000705@icyb.net.ua> <200803271408.24684.jhb@freebsd.org> <47ED02C5.5090804@icyb.net.ua> In-Reply-To: <47ED02C5.5090804@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Nate Lawson Subject: Re: kobj method signature checking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 15:07:34 -0000 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