Good idea, thanks!
On May 20, 2014, at 4:24 PM, Christoph Biedl
sourceforge.b...@manchmal.in-ulm.de wrote:
Ed Cashin wrote...
I was thinking of something like this:
https://github.com/ecashin/vblade/commit/ca2dbda0a35ba686c0ed64e109748129c510fa90
Please let me know if that looks OK
On May 19, 2014, at 6:46 PM, Christoph Biedl
sourceforge.b...@manchmal.in-ulm.de wrote:
Ed Cashin wrote...
... but noticed along the way that you're using atoi. Because
you're supporting 64-bit numbers, would you mind sending a patch
that uses strtoll or doing it in git and sending a pull
I merged that to a new git repo:
https://github.com/ecashin/vblade/
... but noticed along the way that you're using atoi. Because you're
supporting 64-bit numbers, would you mind sending a patch that uses strtoll or
doing it in git and sending a pull request?
On May 11, 2014, at 2:10 PM,
Ed Cashin wrote...
That sounds like a natural complement to your first patch, yes. If
you've got the momentum to whip together the second patch, I could
merge them both at once.
Here you are. The patch below is to replace the original one, so uses
vlong for the offset, and implements a
Ed Cashin wrote...
Thanks. This looks interesting. I like the way you provided a
detailed explanation of the motivation for the patch.
You're welcome.
Do you agree that the offset should be a vlong so that it can
support the same large values that the size can support? An
unsigned int
Thanks. This looks interesting. I like the way you provided a detailed
explanation of the motivation for the patch.
Do you agree that the offset should be a vlong so that it can support the same
large values that the size can support? An unsigned int sometimes isn't going
to be 64 bits.
On
Hello,
the patch below implements a new option -o for vbladed, denoting the
number of sectors that should be skipped at the beginning of the
exported file. Default is 0 (no offset, export from beginning, current
behaviour).
Rationale:
If the exported files are actually raw block devices on the
