On Mon, Apr 11, 2005 at 08:57:05AM -0400, Eric Cooper wrote:
> On Mon, Apr 11, 2005 at 09:46:19AM +0200, Sven Luther wrote:
> > I had plans to do a rewrite of GNU parted, a project which i am
> > involved with, in ocaml, and am being blocked by a few issues.
> > [...]
> >   1) most disk partition tables and filesystem have a mapping from a
> >   given disk 512 byte sector to a descriptive structure.
> >   [...]
> >   or to have access functions which transform parts of
> >   a byte array into values. The first one is ugly, as i was aiming
> >   for a purely ocaml solution (so i can build and arch/plateform
> >   independent bytecode tool), and the second would probably be a
> >   disaster speed wise, and also somewhat ugly unless properly
> >   encapsulated in an abstract module.
> 
> I would use the second approach.  I would define a logically
> equivalent OCaml record or class, and conversion functions between
> that object and a string + offset (or Bigarray of bytes, plus
> offset).  Passing around an offset into a larger byte array can save a
> lot of copying.
> 
> You can probably structure your code so that you only convert to/from
> bytes in a few places, not likely to be performance-critical.

Mmm, one could imagine a generic set of access function inside a byte array
(would have to handle endianess and such though), and then a structure defined
as a set of lazy values corresponding to the access functions in question, so
only values actually accessed get computed.

That said, 

> > Which brings me to the second problem.
> > 
> >   2) Disk descriptors like partition table and filesystems, need to
> >   have exact values, and the values are mostly unsigned 8, 16, 32 or
> >   64 bit integers, strings and bit fields. The int64 and int32 offer
> >   these kind of values, but only the signed version. Is it save to
> >   make calculation on a signed number and ignoring the sign bit ?
> >   Does this not cause risk of overflow ?
> 
> That's the beauty of 2's-complement representation of signed numbers.
> The sign bit is just a consequence of which half of the values encode
> negative numbers, from -1 (0xFF...FF) to min_int (0x80...00), so the
> leading bit is the sign bit.  You can just do arithmetic and interpret
> the results as unsigned.

Ok, but it would be nice to tell this black on white in the manual. I was
half-guessing that something such was the case, but wasn't entirely sure about
the fact, and as well, partitioning is very sensitive stuff, i wanted to be
sure.

Now, what about conversion to Int32 or Int64 ? Would an unsigned Int32 which
is represented as a negative signed Int32 not get broken when used to
calculate Int64 values ? And what about comparisons ? Obviously max_int + 1 >
max_int will be wrong since max_int + 1 would be considered a negative number
(-0 maybe ?).

> >   Also, i believe that bit fields are not easily available, altough
> >   there is some support in the Int32 and int64 bit-wise operators,
> >   but again we have the signed vs unsigned problem, altough it is
> >   maybe ignored for bit operations ?
> 
> You can do anything you need with shifting and masking.  That should
> probably also be hidden in the bytearray-to-record conversion
> routines.

Yeah, bit shifting should be ok, since the sign is ignored for those.

> It would be very cool to have such a "hard core" utility as a
> disk partition editor in OCaml!

Yep, altough having to do ugly hacks in the first part to map the sectors to
ocaml structures is not a good advertizement once you want to convince C users
that it is a better implementation.

Also, the next difficulty is providing C callbacks which are compatible with
libparted.

Friendly,

Sven Luther