From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OKfth-0004IN-6q for mharc-grub-devel@gnu.org; Fri, 04 Jun 2010 19:01:53 -0400 Received: from [140.186.70.92] (port=56352 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKfte-0004Ca-4I for grub-devel@gnu.org; Fri, 04 Jun 2010 19:01:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKftc-0003QN-Lx for grub-devel@gnu.org; Fri, 04 Jun 2010 19:01:49 -0400 Received: from ey-out-1920.google.com ([74.125.78.149]:11063) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKftc-0003QG-EL for grub-devel@gnu.org; Fri, 04 Jun 2010 19:01:48 -0400 Received: by ey-out-1920.google.com with SMTP id 13so321642eye.34 for ; Fri, 04 Jun 2010 16:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=9PBXr1/fkkJr6l9+UqTMH45ugtL5fmyNfLBWaUPuQ9w=; b=ctpI5kLOzFJSt2yEgHObEPbOCy9lGnaOxgZhzpfWzuiZhXTjyBFHMdSfRs+1LKu89n 1bE3mFY1nQdOSP7EcHy1Bzog9xLWWYZnRLN9WeVqGSxh3+cw+/EJOEQUyBEk/mktvorm HDjuSx7FEbJ4RUOtuOFU2hRmC/HXxjp/d79DQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=O/5CVCMTFBPZErNeApcKJ6wsgWoQINWnB3Y6gz7GKmO8cJIm8py8Mjnr4qNc7nrtEH XFtc0YZo993WBFOVWfIIfPX27gNaKuS054FltT+CMt/WOWVYP1mQ81y5fs83PLRXmTR1 l+dWRJ/MR0m+4W0FMBEy1GS150WKUAADWVITU= Received: by 10.213.108.203 with SMTP id g11mr8873265ebp.8.1275692507325; Fri, 04 Jun 2010 16:01:47 -0700 (PDT) Received: from debian.bg45.phnet (gprs01.swisscom-mobile.ch [193.247.250.1]) by mx.google.com with ESMTPS id 15sm994051ewy.4.2010.06.04.16.01.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 16:01:46 -0700 (PDT) Message-ID: <4C0985CB.60506@gmail.com> Date: Sat, 05 Jun 2010 01:01:31 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: The development of GNU GRUB References: <20100603192738.3783.6316.reportbug@rangda.seanius.net> <20100604120928.GY21862@riva.ucam.org> <4C097B95.8050605@gmail.com> <20100604224002.GC21862@riva.ucam.org> In-Reply-To: <20100604224002.GC21862@riva.ucam.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0F1EA4368E44AABB00FEFB01" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: =?utf-8?q?Re=3A_Bug=23584474=3A_FTBFS=3A_usbms=2Ec=3A315=3A_erro?= =?utf-8?b?cjogZm9ybWF0IOKAmCUwMnjigJkgZXhwZWN0cyB0eXBlIOKAmHVuc2lnbmVk?= =?utf-8?b?IGludOKAmQ==?= X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 23:01:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F1EA4368E44AABB00FEFB01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/05/2010 12:40 AM, Colin Watson wrote: > On Sat, Jun 05, 2010 at 12:17:57AM +0200, Vladimir '=CF=86-coder/phcode= r' Serbinenko wrote: > =20 >> On 06/04/2010 02:09 PM, Colin Watson wrote: >> =20 >>> As Vladimir pointed out on IRC: no, that's a minimum field width, not= a >>> precision. It shows *at least* two digits. >>> >>> I think I'd prefer to add a grub_printf length modifier to print >>> grub_size_t values. 'z' is standard for size_t, so it seems reasonab= le >>> to use that, it can be done in very little code, and it saves on ugly= >>> and inaccurate casts. Vladimir, what do you think? >>> =20 >> grub_size_t is always of the same length as long. Perhaps we should >> define it as unsigned long, use "%lx" and get rid of useless differenc= e >> on 32-bit and 64-bit platforms. >> Are there any reasons not to do this way? >> =20 > Good point; I hadn't spotted that. Mostly clarity, I think. If it > comes out as unsigned long anyway then it doesn't make any difference i= n > the machine representation, but the different definitions do seem usefu= l > for clarity. =20 Of course, I've never suggested an elimination of grub_size_t only doing like: typedef unsigned long grub_size_t; > If we change that (I had to read over it a few times to > convince myself), then we should comment it very carefully. A comment > near the #error if GRUB_CPU_SIZEOF_VOID_P !=3D GRUB_CPU_SIZEOF_LONG to = say > that we'll need to change the grub_size_t definition if we ever support= > an architecture where void * isn't the same length as long would also b= e > good, I think. > =20 Ok. We can do the same for grub_addr_t too. > There is no assertion that GRUB_TARGET_SIZEOF_VOID_P =3D=3D > GRUB_TARGET_SIZEOF_LONG, although it's currently true for all targets. > Should there be? > > =20 It can be added but currently GRUB_CPU_SIZEOF_* changes between TARGET_* and HOST_* so if sizes mismatch either util or target part won't compile.= >> Alternatively %zx can be aliased to %lx in one code line. >> =20 > I do like being explicit about the length modifier but I understand tha= t > kern/misc.c needs to be as small as possible, so I'm not going to be > precious about it. How about a compromise along the lines of C99's > to reduce the probability of introducing errors when we ad= d > new targets? Following that (unfortunately ugly) pattern, we'd get > something like: > > #define PRIxGRUB_SIZE "lx" > =20 It's a good idea. Since it will be something heavily used perhaps it's better to make an exception to usual GRUB style and shorten it somehow? But if we do e.g. PRIxG_SIZE we may end up with conflicts with other headers in utils > If you think it's unlikely that grub_size_t will ever need to be > anything other than unsigned long even on future targets, then maybe we= > don't need to worry about that. > > =20 Actualy it's not so much of a "target" as a "compiler-target" pair. Different compilers pick different machine-available sizes on same platform for the same type of int. > Thanks, > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig0F1EA4368E44AABB00FEFB01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkwJhcsACgkQNak7dOguQgms4QEAszBNNurdlQeqfsU4hTe+rq0E gRWLiux085ZvW6TAs8YA/jLWwMWzf1X5XQmTi1gmSkJnktCLQmgnthVxtJTsMpLo =CnZF -----END PGP SIGNATURE----- --------------enig0F1EA4368E44AABB00FEFB01--