Re: [patch] Solved problems with file size >2GB
On Mon, Apr 24, 2006 at 01:08:19PM -0700, Brendan Cully wrote:
> On Monday, 24 April 2006 at 10:17, Bruno Cesar Ribas wrote:
> > On Mon, Apr 24, 2006 at 03:04:35PM +0200, Ralf Wildenhues wrote:
> > > Hi Bruno,
> > >
> > > * Bruno Cesar Ribas wrote on Mon, Apr 24, 2006 at 02:46:31PM CEST:
> > > >
> > > > Even if we have a limited audience for this bug, we have a bug and
> > > > people
> > > > suffering from this bug. =)
> > > > And if we have a correction why not apply?
> > >
> > > Your patch includes inttypes.h unconditionally, which I could imagine
> > > not to be portable to all system mutt aims to support. Mutt could maybe
> > > make use of Gnulib's inttypes module. But even that won't guarantee you
> > > all the stuff that this patch needs. Anyway this patch needs more work
> > > (sorry for not having the time to delve any deeper into this).
> >
> > Okay!! I'll take inttypes.h out and make it more portable =) no problem, i
> > thought that using it would be better, but not all systems have it you are
> > right.
> > About more work neeeded, what do do you mean [without deeper information]?
> > I think i'll make a pattern for off_t types in the code and then i'll send
> > again =)
>
> Mutt already defines LOFF_T and OFF_T_FMT macros for several
> operations on large files. Could you not use them for display as well?
I saw that, but i'll have to redefine it because OFF_T_FMT as "%lld" but
sometimes i'll need only 'lld' because there are that spaces do align, today
it is used like : "%%sld",fmt , where fmt is the 'number' but that's easy to
fix.
But the main problem was that most variables where only 'long int' or 'int'
or 'size_t' instead of 'off_t', and some casts to 'long' .
I had put the 'inttypes.h' because I thought it was a good way because it's a
system header [and now i found out that not all systems have] and have only
macros verifying if we passed a 64bit
I agree that we could just make those OFF_T macros if we cant find that
macros header [inttypes.h]
--
Bruno Ribas - ribas@xxxxxxx