[Haskell-cafe] GHC 7.0.1 developer challenges

[John D. Ramsdell]

A quick review of GHC 7.0.1 revealed two challenges for developers.

I downloaded the GHC 7.0.1 sources, configured for a home directory
install, and built and installed the compiler.  Very close to the end,
my machine froze, perhaps due to memory exhaustion.  In any event, a
reboot allowed me to complete the installation.

I tested the new compiler on an application I distribute, CPSA.  The
algorithm implemented by the program is not guaranteed to terminate,
and it's hard to predict when non-termination is inevitable.
Sometimes the way it terminates is to allocate all the memory in swap
space and freeze the machine.  It's an ugly crash.  So in my
documentation, I recommend people supply a runtime flag limiting
memory usage.

Due to a security concern, GHC 7.0.1 disables all runtime flags unless
a new flag is provided during linking.  Since limiting memory usage is
so important, many developers will modify their cabal files to add the
linker flag or prepare for complaints from users that the developer's
program caused their machine to freeze and lose their work.

The irony of this situation is deep.  CPSA is a program that analyzes
cryptographic protocols in an effort to expose security flaws.  To
ensure that the program does not crash a user's machine, I have to use
a linker option that may expose the user to some security problems.

There is one more disappointment in GHC 7.0.1 for developers.  Cabal
sdist is still hosed.  Since ten months ago, cabal sdist fails to
preserve the file mode bits of the source files put into the tarball
being generated (Ticket #627 reported by draconx). An executable shell
script and a source file world readable both have a mode of 600 in the
tarball!  So developers, continue to keep GHC 6.10.4 around so you can
create source distributions.  That's what I do.

John