bug-ddrescue
[Top][All Lists]
Advanced

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

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


From: Martin Koeppe
Subject: [Bug-ddrescue] ddrescue patch for unsigned/signed compiler warnings
Date: Mon, 22 Feb 2010 23:49:15 +0100 (CET)


Hi Antonio,

here comes my patch against 1.11 so that MSVC is happy and doesn't issue signed/unsigned warnings anymore. I currently let size_ as long long, see below for why one might consider to change that.

Martin


Hi Antonio,

first of all thank you for creating gddrescue.
It's very useful and has the features that dd is missing.

Unfortunately gddrescue is not available for Windows. As I can need it there, I tried to port it. Porting is relatively easy due to C++ usage, so a second thank you for that.

But the issue I have is that the MS compiler warns about signed/unsigned implicit conversions. I looked into it and several trivial cases exist where "int" can be substituted by "size_t", e.g. when counting the index for looping through a vector<>.

One case isn't quite obvious to me, however:
Why is in block.h, class Block, element size_ defined as long long?
In ddrescue.cc readblock() is called several times with such a long long sized block as parameter. readblock() itself doesn't accept long long for size, and the underlying read() probably won't accept that on any system. I think the maximum block size that can ever be read by one call to read() is max(size_t).

So are there reasons for Block::size_ being long long or should that be changed to size_t, to eliminate compiler warnings?

I'll send you my patch soon, in the hope you will accept it and so make it easily possible to build gddrescue for Windows. It already builds fine, but isn't tested very much currently.

Also I'll try to integrate a nice feature for Windows found in
http://www.chrysocome.net/dd
i.e. the --list switch, which shows the available block device names.


Regards

Martin

Attachment: unsigned.diff
Description: Text Data


reply via email to

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