bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-ddrescue] Re: ddrescue patch for unsigned/signed compiler warnings


From: Martin Koeppe
Subject: [Bug-ddrescue] Re: ddrescue patch for unsigned/signed compiler warnings
Date: Sun, 28 Feb 2010 11:11:57 +0100

Hi Antonio,
 
> Martin Koeppe wrote:
>  > Unfortunately gddrescue is not available for Windows.
> 
> There is at least a cygwin port of ddrescue. Just search for "ddrescue 
> cygwin".

yes, but I prefer a native Windows build because I need it on many different 
boxes and only occasionally on one particular box. And all of the boxes don't 
have cygwin installed.

>  > One case isn't quite obvious to me, however:
>  > Why is in block.h, class Block, element size_ defined as long long?
> 
> Because it needs to be at least 64 bits long.

Why? As I could see, one block is filled by one readblock(), and one 
readblock() calls one read() which can't read a long long number of bytes. 
I'm not sure if I got this right, however.
Somewhere the sum of several blocks is calculated. Obviously, this sum should 
be long long. However, I saw a use of -1 in the size_ field.
 
>  > In ddrescue.cc readblock() is called several times with such a long
> long
>  > sized block as parameter.
> 
> If your compiler barks at this, I can easily solve it with a cast. The 
> real value never exceeds what readblock can accept.

Yes, I in between have got around this with the patch I already sent. I only 
wanted to understand how the algorithm works.

>  > here comes my patch against 1.11 so that MSVC is happy and doesn't
> issue signed/unsigned warnings anymore.
> 
> I think there are no real signed/unsigned issues in ddrescue; no value 
> ever exceeds the maximum positive signed value. I'll try to fix all the 
> signed/unsigned warnings you get, but I can't apply your patch because 
> it breaks build in GNU systems.

Where exactly does it break? I can make a new version, if you like.
The os.h thing was only my suggestion and is not fully worked out yet. For 
Windows I unfortunately can't use open() and therefore probably read() eeither, 
because open() on Windows cannot access raw devices. This needs CreateFile(). I 
haven't worked out this yet.

I think that in all loops such as
for (i=0; i<vector<>::size(); i++)
i should be of the same type as size() returns. That's not int and not unsigned 
int either, but size_t. Also all member functions returning the size of a 
vector should return size_t also.
Every index access, i.e. anything within [] should be of type size_t, or at 
least unsigned.

Regards
Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]