From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 23:25:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2571065670; Sun, 28 Dec 2008 23:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id AA23A8FC13; Sun, 28 Dec 2008 23:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F0AF341C707; Mon, 29 Dec 2008 00:25:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vPJiwmeAY+EE; Mon, 29 Dec 2008 00:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 95F8B41C72C; Mon, 29 Dec 2008 00:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7DF364448D5; Sun, 28 Dec 2008 23:24:46 +0000 (UTC) Date: Sun, 28 Dec 2008 23:24:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Qing Li Message-ID: <20081228225956.G28465@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Kip Macy Subject: arp-v2 (void *)-1 "hack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2008 23:25:08 -0000 Hi, Cc:ing freebsd-net as I came across the (void *)-1 "hack" 1.5 weeks ago while debugging some problems with others and they might be interested as well. I was sure I hadn't seen that hack in patches posted before. I spent some time today and looked a bit more into it (also comitted the LLE_IS_VALID() check). In short: I don't like it and I don't understand why a new API needs a hack already that is passed down through two functions into the code. It was introduced the last days before the commit. I found r186010 and r186027 in SVN but that's just two of the 4 places. I think the proper behavior would be to either return an "errno" or the lle via an additional argument and the other as return value. As the lle is the return value already I would say adding an extra argument 'int *error' will be easier. For now this seems to only affect LLE_DELETE cases but I am not sure all (especially wrt to the future of v6) has been shaken out yet and returning a proper error code (possibly along with the NULL lle) would make this more flexible. I am also not sure if all the "void" callers on delete are right but I got distracted by a "dead" function in one of the callpaths while investigating. What do you think wrt to adding the (possibly optional) int *error and returning the errno rather than a (void *)-1? If you'd be ok, I'd can prepare the patch. I'd rather break the API now than in a few months. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.