Re: [Ocaml-lib-devel] Future of ExtLib

[Brian H. <bh...@sp...>]

On Fri, 9 Apr 2004, Sylvain LE GALL wrote:

> > Actually, writting portable C isn't the problem.  I routinely write C code 
> > which is much more widely portable than Ocaml is.  
> > 
> 
> Well, most of the time, porting from BE to LEndian and trading with
> different int size is a great problem ( for me at least ). You need a
> lot of #define #ifdef... I don't like this... Test coverage for code is
> enough difficult. Adding compile time condition give you more code to
> test...

Worse yet, I've worked on systems which were *neither* BE nor LE (hint:
DEC tried to switch horses in midstream).  BE/LE only come into play when
you're reading/writting binary data, or playing games with unions.  In the
first case, I tend to construct my ints by hand to control endianess.  If 
you're doing I/O, the extra shift/ors aren't that big of a problem.  As 
for playing games with unions, these are bad ideas anyways, don't do them.

As for int sizes, all this means is you need to think about what types 
things are.  One of the worst habits C coders get into is not thinking 
about what types variables should be.  I'd argue this is more important in 
C than it is in Ocaml.  An example: what type should the variable i be in 
the following code?
    for (i = 0; i < sizeof(arr)/sizeof(arr[0]); ++i) {
        arr[i] = 0;
    }
My answer: i should have the type size_t.  Thinking about what types 
variables should be solves most of the problems (and eliminates the vast 
majority of pointless typecasts).

I hate ifdefs, except for providing imdepotence for header files (at which 
point I insist on them).  But it's surprising how portable you can get 
without them.

> I agree...
> 
> The idea of having zlib, encryption is good but i think it should be not
> part of extlib.

That's where I'm ending up as well.  Or at least not C-based encryption 
and compression.  Ocaml code only.  Note that there might be a sister 
project spawned to use the C code for higher performance.

> ps : do you plan to use cryptokit and cryptgps for your library ?

I hadn't thought about it much.  Last time I took a spin through the 
crypto libraries, I was more than a little surprised that not one used GMP 
for RSA.  Which I found quite surprising, as I'm willing to bet that GMP 
would give you the best possible RSA performance with the least work from 
the implementor.  IIRC, GMP already has an "exponentiate in a modular 
field" operation, implemented with tuned assembly code.  This is the core 
operation of RSA.  For symmetric key and hashing, I was thinking of 
rounding up the hand-tunned assembly versions kicking around.  I haven't 
decided what to do with Elliptic curve yet.

Thinking about it a second, there's a problem with providing Ocaml 
implementations of various symmetric key crypto systems- most of them
assume you have access to efficient 32-bit integers.  Which means you 
either use Int32 at a serious performance and memory hit.  

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian