>We use loff_t in the .defs files for clarity, though they are the
>same as the Hurd sources are compiled.
>
> So loff_t in .defs, and off_t everywhere else? Or off_t everywhere?
>
> I prefer the last one.
off_t sometimes differs and loff_t never does. The Hurd sources themselves
have
We use loff_t in the .defs files for clarity, though they are the
same as the Hurd sources are compiled.
So loff_t in .defs, and off_t everywhere else? Or off_t everywhere?
I prefer the last one.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http
We use loff_t in the .defs files for clarity, though they are the same as
the Hurd sources are compiled.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
>So why not off_t in the structure instead?
>
> Well, either we use off_t or we use loff_t (or even off64_t). Is
> there any rule as to what should be used? Because I don't have a
> real opinion about it (other then maybe that loff_t is clearer
> then off_t)
Well, we sh
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>So why not off_t in the structure instead?
>
> Well, either we use off_t or we use loff_t (or even off64_t). Is
> there any rule as to what should be used? Because I don't have a real
> opinion about it (other then maybe that loff_t is clearer
So why not off_t in the structure instead?
Well, either we use off_t or we use loff_t (or even off64_t). Is
there any rule as to what should be used? Because I don't have a real
opinion about it (other then maybe that loff_t is clearer then off_t)
___
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Also, one should look to all the users of the field in question (in
>the library itself and also in the programs that use the library,
>at least ufs and ext2fs) and see what kinds of local variables they
>are using to hold values in t
Also, one should look to all the users of the field in question (in
the library itself and also in the programs that use the library,
at least ufs and ext2fs) and see what kinds of local variables they
are using to hold values in the field, and function parameters that
are connected
Well, for a change like this you should certainly check that a wholly
rebuilt system still works for some normal minor stress tests.
Yeah, but my setup ain't exactly "do a quick test" friendly sadly
which is why I didn't test it more. I can do a small stress test
though, but it will take so
Roland McGrath <[EMAIL PROTECTED]> writes:
> Well, for a change like this you should certainly check that a wholly
> rebuilt system still works for some normal minor stress tests.
Also, one should look to all the users of the field in question (in
the library itself and also in the programs that
Well, for a change like this you should certainly check that a wholly
rebuilt system still works for some normal minor stress tests.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
Have you tested that this produces no new warnings and so forth?
Only checked that it didn't produce any warnings.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
Have you tested that this produces no new warnings and so forth?
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
I don't see any logical reason for filepointer to be a int here.
libdiskfs/ChangeLog
2004-09-28 Alfred M. Szmidt <[EMAIL PROTECTED]>
* diskfs.h (struct peropen): Changed member type of
`filepointer' from `int' to `loff_t'.
--- libdiskfs/diskfs.h 27 Jun 2002 21:19:13 +0200
14 matches
Mail list logo
