On Wed, 15 Sep 1999, Warner Losh wrote:
> In message <199909151928.vaa26...@dorifer.heim3.tu-clausthal.de> Oliver
> Fromme writes:
> : It only works on two's-complement machines, though, but I'm not
> : aware of any FreeBSD port to an architecture that doesn't use
> : two's-complement numbers...
On Wed, 15 Sep 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Oliver Fromme
>writes:
> : It only works on two's-complement machines, though, but I'm not
> : aware of any FreeBSD port to an architecture that doesn't use
> : two's-complement numbers...
>
> I'm not aware of any one's-co
On Wed, 15 Sep 1999, Jordan K. Hubbard wrote:
> It can go in after the freeze - it's a bit late to be asking now. :)
I was guessing as much :) I didn't specifically see anyone requesting
for these things in -STABLE, so I didn't really pay much attention to
merging these things. It makes me wonde
It can go in after the freeze - it's a bit late to be asking now. :)
> On Wed, 15 Sep 1999, Dan Nelson wrote:
>
> > RCS file: /home/ncvs/src/bin/dd/dd.c,v
> >
> > revision 1.17
> > date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
On Wed, 15 Sep 1999, Dan Nelson wrote:
> RCS file: /home/ncvs/src/bin/dd/dd.c,v
>
>
> revision 1.17
> date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
> Miscellaneous dd(1) changes: mainly fixing variable types (size_t,
> ssize_t,
On Wed, 15 Sep 1999, Jordan K. Hubbard wrote:
> It can go in after the freeze - it's a bit late to be asking now. :)
I was guessing as much :) I didn't specifically see anyone requesting
for these things in -STABLE, so I didn't really pay much attention to
merging these things. It makes me wond
It can go in after the freeze - it's a bit late to be asking now. :)
> On Wed, 15 Sep 1999, Dan Nelson wrote:
>
> > RCS file: /home/ncvs/src/bin/dd/dd.c,v
> >
> > revision 1.17
> > date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
On Wed, 15 Sep 1999, Dan Nelson wrote:
> RCS file: /home/ncvs/src/bin/dd/dd.c,v
>
> revision 1.17
> date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
> Miscellaneous dd(1) changes: mainly fixing variable types (size_t,
> ssize_t, of
In message <199909151928.vaa26...@dorifer.heim3.tu-clausthal.de> Oliver Fromme
writes:
: It only works on two's-complement machines, though, but I'm not
: aware of any FreeBSD port to an architecture that doesn't use
: two's-complement numbers...
I'm not aware of any one's-complement machine that
In message <[EMAIL PROTECTED]> Oliver Fromme writes:
: It only works on two's-complement machines, though, but I'm not
: aware of any FreeBSD port to an architecture that doesn't use
: two's-complement numbers...
I'm not aware of any one's-complement machine that was manufacture
after about 1980.
Bakul Shah wrote in list.freebsd-hackers:
> [...]
> Let me say it another way. The bugfix should be accepted and
> another PR be filed that says there needs to be a constant
> defining the largest possible off_t value. Also note that
> traditionally Unix does not define max values for every
> date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
> Miscellaneous dd(1) changes: mainly fixing variable types (size_t,
> ssize_t, off_t, int, u_int64_t, etc.). dd(1) should now work properly
> with REALLY big amounts of data.
>
> Should be a -stable candidate by now (3 mont
Bakul Shah wrote in list.freebsd-hackers:
> [...]
> Let me say it another way. The bugfix should be accepted and
> another PR be filed that says there needs to be a constant
> defining the largest possible off_t value. Also note that
> traditionally Unix does not define max values for every
> date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
> Miscellaneous dd(1) changes: mainly fixing variable types (size_t,
> ssize_t, off_t, int, u_int64_t, etc.). dd(1) should now work properly
> with REALLY big amounts of data.
>
> Should be a -stable candidate by now (3 mon
In the last episode (Sep 15), Bakul Shah said:
> PR bin/6509 (submitted in May 1998) already has a patch to fix this
> but it was rejected because off_t was assumed by the bug
> fixer/submitter to be a quat (int64_t). I can't even get an IDE disk
> below 2G byte easily! And we are still years awa
In the last episode (Sep 15), Bakul Shah said:
> PR bin/6509 (submitted in May 1998) already has a patch to fix this
> but it was rejected because off_t was assumed by the bug
> fixer/submitter to be a quat (int64_t). I can't even get an IDE disk
> below 2G byte easily! And we are still years aw
PR bin/6509 (submitted in May 1998) already has a patch to
fix this but it was rejected because off_t was assumed by the
bug fixer/submitter to be a quat (int64_t). I can't even get
an IDE disk below 2G byte easily! And we are still years
away from zettabyte disks. So I don't see the point of
b
PR bin/6509 (submitted in May 1998) already has a patch to
fix this but it was rejected because off_t was assumed by the
bug fixer/submitter to be a quat (int64_t). I can't even get
an IDE disk below 2G byte easily! And we are still years
away from zettabyte disks. So I don't see the point of
bl
18 matches
Mail list logo
