From owner-svn-src-all@FreeBSD.ORG Fri Aug 13 10:25:38 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5141065696; Fri, 13 Aug 2010 10:25:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA838FC15; Fri, 13 Aug 2010 10:25:37 +0000 (UTC) Received: from c122-106-147-41.carlnfd1.nsw.optusnet.com.au (c122-106-147-41.carlnfd1.nsw.optusnet.com.au [122.106.147.41]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7DAPSwP004848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 20:25:29 +1000 Date: Fri, 13 Aug 2010 20:25:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <4C643352.5010508@FreeBSD.org> Message-ID: <20100813200216.U12816@delplex.bde.org> References: <201008121358.o7CDwk0d098768@svn.freebsd.org> <86pqxn50vr.fsf@ds4.des.no> <4C6414A7.6020306@FreeBSD.org> <868w4bda7e.fsf@ds4.des.no> <4C643352.5010508@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1130892370-1281695128=:12816" Cc: svn-src-head@FreeBSD.org, =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Takanori Watanabe Subject: Re: svn commit: r211221 - head/usr.sbin/acpi/acpidump X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:25:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1130892370-1281695128=:12816 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 12 Aug 2010, John Baldwin wrote: > Dag-Erling Sm=C3=B8rgrav wrote: >> John Baldwin writes: >>> Dag-Erling Sm=C3=B8rgrav writes: Oops, I replied to the commit mail for the round after this before noticing this thread. >>>> Slightly better: >>>>=20 >>>> =09printf("\tClass %u Base Address 0x%jx Length %ju\n\n", >>>> =09 (unsigned int)tcpa->platform_class, (uintmax_t)paddr,=20 >>>> (uintmax_t)len); Ugh, this has many more style bugs: - `unsigned int' is spelled u_int in KNF, partly to try to avoid the next bug - `platform_class' has type uint16_t. u_int is larger than that on all supported machines, and also on unsupported ones with 16-31 bit u_ints. Thus the cast has almost no effect, and has no effect on the result. On unsupported machines with exactly 16-bit u_ints, it has no effect. On unsupported and supported machines with >=3D 17-bit ints, the arg gets promoted to a signed int thanks to C90's promotion botch, but the value of the signed int is nonnegative so there is no difference here from the result of an unbotched promotion to u_int. - the second line is too ling, and has been nicely mangled by mailers, first by putting a hard newline in it and then by quoting it. >>>> but it would probably be easier to define paddr and len as unsigned lo= ng >>>> long instead of the misspelled u_int64_t, and use %llx and %llu. >>> Depends. If the table defines a field to be a 64-bit integer, it is >>> better to use an explicitly-64-bit integer type such as uint64_t >>> rather than assuming that 'long long' is 64-bit. Nah, unsigned long long shouldn't exist. >> Actually, paddr and len are a memory address and an object size, >> respectively, so the logical thing would be to use uintptr_t and size_t >> with uintmax_t casts... vm_offset_t and vm_size_t would be more logical, but maybe they are too BSD(Mach vm)-specific for acpi, especially outside of the kernel. > Except that physical addresses do not always fit in uintptr_t on i386 (th= ink=20 > PAE with 36-bit physical addresses and 32-bit uintptr_t, same for the=20 > length). If they truly were a size_t you could use %z without a uintmax_= t=20 > cast. Yes, if paddr really means a physical and not a virtual memory address. PAE has vm_paddr_t for the former. vm_paddr_t is 32 bits without PAE and 64 bits with PAE. Printing it and otherwise using it gives the usual problem that _no_ typedefed type can be printed or otherwise used with a hard-coded format or type (other than the typedef), but bugs are more noticable than usual since the type varies widely within a single arch. Anyway, almost all typedefed types should be cast to [u]intmax_t for printing, so that you don't have to know too much about what they are. We are still very sloppy about this for the smaller types, but have to be more careful for 64-bit types. Sloppy printing of the smaller types will break eventually when int or long expands but the typedefs don't. Bruce --0-1130892370-1281695128=:12816--