From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Eliminating grub_size_t
Date: Wed, 02 Jul 2008 20:46:25 +0300 [thread overview]
Message-ID: <486BBEF1.6000105@nic.fi> (raw)
In-Reply-To: <20080702002031.7gkuoel14wg80c0k-cebfxv@webmail.spamcop.net>
Pavel Roskin wrote:
> Quoting Javier Martín <lordhabbit@gmail.com>:
>
>> El mar, 01-07-2008 a las 22:14 -0400, Pavel Roskin escribió:
>>> 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.
>> I'm not sure if I'm getting you right. Are you suggesting that we "undo"
>> the someinteger->size_t conversion that caused so many headaches in many
>> 32->64 bit ports? Machine-dependant types like size_t and ptrdiff_t are
>> here to help us, not to haunt us. What is the exact problem with size_t
>> in GRUB right now? I agree that grub_size_t is redundant, though.
>
> No real problem. There are some warnings in fs/reiserfs.c about it.
> But I think removing or redefining grub_size_t would be the cleanest
> solution.
If reiserfs is using it in wrong place, fix the reiserfs. If you are
reading some file system variable, then you should use grub_uintN_t to
specify storage size in bits.
size_t is usually used as common index or offset (or size) to some
buffer. size_t is returned by sizeof(). It is meant to be optimal size
for platform. Eg. on 64bit memory bus it is 64bit and on 32bit memory
bus it is 32bit. What grub is doing here is just defining yet another
type for the same thing.
Google for size_t if you want to find out more about it.
next prev parent reply other threads:[~2008-07-02 17:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 2:14 Eliminating grub_size_t Pavel Roskin
2008-07-02 2:33 ` Javier Martín
2008-07-02 4:20 ` Pavel Roskin
2008-07-02 10:26 ` Isaac Dupree
2008-07-02 13:23 ` Pavel Roskin
2008-07-02 17:46 ` Vesa Jääskeläinen [this message]
2008-07-02 17:51 ` Pavel Roskin
2008-07-03 18:02 ` Marco Gerards
2008-07-03 18:29 ` Pavel Roskin
2008-07-03 18:42 ` Vesa Jääskeläinen
2008-07-03 18:52 ` Pavel Roskin
2008-07-03 19:07 ` Vesa Jääskeläinen
2008-07-03 19:16 ` Pavel Roskin
2008-07-03 18:56 ` Marco Gerards
2008-07-03 19:05 ` Pavel Roskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=486BBEF1.6000105@nic.fi \
--to=chaac@nic.fi \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.