From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KDrrq-0000bt-Cv for mharc-grub-devel@gnu.org; Tue, 01 Jul 2008 22:14:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDrro-0000ad-Fy for grub-devel@gnu.org; Tue, 01 Jul 2008 22:14:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDrrn-0000ZQ-4g for grub-devel@gnu.org; Tue, 01 Jul 2008 22:14:44 -0400 Received: from [199.232.76.173] (port=55003 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDrrm-0000ZN-US for grub-devel@gnu.org; Tue, 01 Jul 2008 22:14:42 -0400 Received: from c60.cesmail.net ([216.154.195.49]:55132) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KDrrm-0004mh-Pc for grub-devel@gnu.org; Tue, 01 Jul 2008 22:14:42 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 01 Jul 2008 22:14:41 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id AD2F4618F22 for ; Tue, 1 Jul 2008 22:14:41 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 Content-Type: text/plain Date: Tue, 01 Jul 2008 22:14:40 -0400 Message-Id: <1214964880.7362.17.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Eliminating grub_size_t X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2008 02:14:44 -0000 Hello! I wonder if we would be better off without grub_size_t. I cannot think of any code that could use it legitimately. The ordinary size_t is used to represent the result of sizeof, i.e. size of a structure. There is no need for grub to support data structures exceeding 4 gigabytes. If we want to support more memory, that's fine, but that would involve other types that can hold the pointer values, such as long. size_t has different size on 32-bit and 64-bit systems, but we should strive to make the userspace utilities work like the bootloader, so that possible problems can be detected early and debugged easily. Besides, we cannot even print size_t in grub_printf(), and I don't think we should. grub_size_t should be replaced with int or grub_uint32_t. size_t can be used in pure userspace code to call functions that need it. -- Regards, Pavel Roskin