Re: Eliminating grub_size_t

[Pavel Roskin]

Quoting Javier Martín <address@hidden>:

> 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.

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

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.

--
Regards,
Pavel Roskin