Re: Eliminating grub_size_t

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

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.
> 
> 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
bootloader?"
> 
> 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?
> 
> 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.
> 

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]