[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eliminating grub_size_t

From: Pavel Roskin
Subject: Re: Eliminating grub_size_t
Date: Wed, 02 Jul 2008 00:20:31 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)

Quoting Javier Martín <address@hidden>:

El mar, 01-07-2008 a las 22:14 -0400, Pavel Roskin escribió:

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.

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.
I didn't understand this. What do you mean with "US working like the

I mean that if, say, GRUB fails to read reiserfs, I'd like to be able to reproduce the problem in grub-fstest even if I'm compiling it on x86_64.

Besides, we cannot even print size_t in grub_printf(), and I don't think
we should.
1. that can be worked out
2. why not?

We want to save space, not to add code just for a good feeling that out printf is a s good as the one in glibc.

Pavel Roskin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]