From owner-freebsd-current@FreeBSD.ORG Mon Dec 29 10:23:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80441065673; Mon, 29 Dec 2008 10:23:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 21A108FC0C; Mon, 29 Dec 2008 10:23:10 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pgw_eo6bRDYA:10 a=JgwOP_QsqSoA:10 a=kd14tShcpvOT4kO6TbkA:9 a=LuOMy-X7fWvorRIIuqDvtpnagaAA:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [193.217.167.134] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 427103097; Mon, 29 Dec 2008 11:23:09 +0100 From: Hans Petter Selasky To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Mon, 29 Dec 2008 11:25:28 +0100 User-Agent: KMail/1.9.7 References: <20081222214010.GA18389@elvis.mu.org> <200812231736.29198.hselasky@c2i.net> <86d4fb72se.fsf@ds4.des.no> In-Reply-To: <86d4fb72se.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200812291125.30222.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 10:23:12 -0000 On Monday 29 December 2008, Dag-Erling Sm=C3=B8rgrav wrote: > Hans Petter Selasky writes: > > LIBUSB20_ADD_BYTES() is a hack to circumvent things like un-constifying > > and making a byte increment to any pointer type. USB descriptors are > > byte-packed. I have tested the macro with several kinds of compilers and > > none have complained yet. > > 1) if you need to de-constify, your API is broken. The following function is a candidate for de-constifying. You have a data=20 pointer there which is read or write, and to be able to transfer constant=20 data you need to do a deconst before passing the pointer to this function. usb2_do_request_flags(struct usb2_device *udev, struct mtx *mtx, struct usb2_device_request *req, void *data, uint32_t flags, uint16_t *actlen, uint32_t timeout) Deconstifying is not illegal in C using standard pointer arithmetics. (void *)((const uint8_t *)(ptr) - (const uint8_t *)0) > > 2) just because the compiler doesn't know it's wrong doesn't mean it > isn't. > > 3) the pointer magic you do in (for instance) libusb20_me_encode() and > libusb20_me_decode() won't work on strict-alignment platforms. > Yes, it will, because all addresses are aligned before they get casted. =2D-HPS