SCSI tape data loss

[Kern Sibbald]

I cannot argue with what you write other than to
say that I generally use uint32_t for variables that
are positive integers, so I have them everywhere and
to change wlen to signed would lead to a flood of
changes of other variables. If I remember right one
thing that pushed me in this direction is the fact
that sizeof() is unsigned.

By the way, I've just completed a much simpler test
that I ask Dan to try to see if we can reproduce the
problem in a simpler case.

Best regards,

Kern

On Tue, 2003-06-03 at 21:13, Justin T. Gibbs wrote:
> >> > By the way, the funny casting is mandatory in C++,
> >> > because ssize_t as returned by the write is not the 
> >> > same as size_t (what is written).
> > 
> > If I remove the (uint32_t) cast, I get an error message:
> > 
> > c++   -c   -I. -I..  -g -O2 -Wall  block.c
> > block.c: In function `int write_block_to_dev (JCR *, DEVICE *, 
> > DEV_BLOCK *)':
> > block.c:381: warning: comparison between signed and unsigned integer 
> > expressions
> > 
> > Line 381 reads:
> > 
> >    if ((stat=write(dev->fd, block->buf, (size_t)wlen)) != wlen) {
> > 
> > so I will stick with my funny casting.
> > 
> 
> This has nothing to do with type size or the fact that you are
> using C++.  The same warning would occur when your code is
> compiled as C.  wlen should be a signed type.  Since wlen
> by definition cannot be larger than the largest positive integer
> reportable by the signed return value of write, using an unsigned
> type buys you nothing.  Conversion from ssize_t to size_t will
> occur without error if you happen to chose to make wlen an ssize_t.
> 
> I guess it matters little.  My own philosophy is that casts should
> be used as a last resort rather than deployed indiscriminantly to
> cover up compile warnings.  The above casts are easily avoidable
> which is why I mentioned them at all.
> 
> --
> Justin