Windows registry handling / hugs CVS repository?

[Andre Santos]

I strongly support the request for the fix to the problems
related to the Windows registry prolems. We have problems very often
in our labs or in student's computers where the registry entry is
corrupted
and it is very hard for them (and for us) to change the registry to fix
it.

Andre.

Antony Courtney wrote:
> 
> Hi,
> 
> I think that the way hugs uses the registry under Windows is dangerous and
> buggy.  This message describes the problems and proposes some alternative
> designs.  I welcome comments and suggestions.
> 
> "dangerous":
> 
> In the current design, any options changes made interactively using ":set" from
> the hugs prompt are ALWAYS saved immediately to the registry.  This is all well
> and good when the user actually made an intended change, but it is an brutally
> unforgiving of mistakes.
> 
> Consider the common scenario of someone attempting to add a component to the
> search path using something like:
>         Prelude> :set -Pc:\my\lib\path
> Ooops!  The user forgot to include a ';' in the search path to append or prepend
> this path to the existing search path.  Thanks to the automatic save-to-registry
> "feature", there is no way to undo this change.  Even if the user quits and
> restarts hugs, the search path will only contain this one component.  The
> original hugs default search path, as well as any changes made to the search
> path since hugs was installed on the system, are now GONE FOREVER!  In fact, the
> only way I know of to recover the default search path is to re-install hugs from
> scratch.
> 
> "buggy":
> 
> During a desperate last minute demo preparation recently (for Paul Hudak's
> class), I had to append a few things to my search path using something like:
>   Prelude> :set -P;c:\some\big\long\hairy\path
> At some point, I crossed some small magic size limit, and *poof!*:  next time I
> started hugs, all of my path changes since hugs had been installed silently
> disappeared, and the path reverted to the system default path!   If you want to
> see this bug yourself, simply run the above command a bunch of times (maybe 6 to
> 10), restart hugs, and do a ":set" to see the bogus value for path.
> 
> I did a little digging around in the code (from Feb2001 release of hugs), and
> found the following
> 
> First, in hugs.c, the implementation of optionsToStr() looks like this:
> 
> static String local optionsToStr() {
>      static char buffer[2000];
> 
>      (...bunch of code to add things to buffer, with no buffer overrun
> checks...)
> 
>      return buffer;
> }
> 
> Then, in machdep.c, we have:
> 
> static Sting local readRegString(...)
> ...
> {
> #if HUGS_FOR_WINDOWS
>     static char buf[2048];
> #else
>     static char buf[300];
> #endif
>     if (queryValue(...buf, sizeof(buf)) == REG_SZ) {
>         /* success */
>         return buf;
>      } else {
>         return def;  /* system default option settings */
>      }
> }
> 
> Here is my short list of bugs in the above code:
> 
> 1.  Fixed size buffers are a dangerous practice.  If you must use them, at least
> make sure they are large enough to hold the largest conceivable value and then
> some.  In this case, 2048 bytes is a reasonable size; 300 is not.  It turns out
> that the HUGS_FOR_WINDOWS preprocessor symbol is only defined when building the
> rarely used Windows GUI for hugs, not the ordinary Windows version.  I *STRONGLY
> RECOMMEND* just getting rid of the #if..#endif, and using the larger buffer
> size.  I'm fairly certain this is the cause of the bug I noted above.
> 
> 2.  It's unfortunate that the code in the first function doesn't check for
> buffer overruns, but at least a 2000 byte buffer is (somewhat) reasonable.
> 
> 3.  Both of these functions return a pointer to automatic (i.e. stack allocated)
> variables.  This is a classic dangling pointer bug, and the behavior of such a
> program is undefined according to the ANSI C standard.  (IF you happen not to
> have any function calls between where the pointer is returned and where the
> pointer is used in the calling code, and IF your compiler happens to implement
> automatic variables using a stack, then you might "get lucky" and your program
> might behave as intended, but there is no guarantee this will work.)  A simple
> solution is to allocate the buffer in the caller's stack frame and pass a
> pointer to the callee.
> 
> -----
> 
> My radical alternative design proposal:
> 
> -  Do NOT automatically save settings to the Windows registry.  I hope the
> "dangerous" paragraph above is enough to convince anyone that this is just a bad
> idea.
> 
> -  As a convenience, after reading HUGSFLAGS from the environment, also read an
> environment variable HUGSPATH.  Allow empty path components to be used to
> specify the current path (to prepend / append), as we do now.
> 
> If absolutely necessary, we could provide a ":regsave" command to allow the user
> to explicitly save changes made to hugs options to the registry.  Personally, I
> don't think this is necessary, but I'd be happy to hear others' opinions.
> 
> I welcome comments / discussion on this proposal.  Using environment variables
> for such settings is cross-platform, well understood, reasonably standard, and
> avoids the dangers of this automatic save-to-registry.
> 
> I volunteer to implement the above changes, if someone would be so kind as to
> point me towards the hugs CVS repository.
> 
>         -antony
> 
> --
> Antony Courtney
> Grad. Student, Dept. of Computer Science, Yale University
> antony@apocalypse.org          http://www.apocalypse.org/pub/u/antony
> 
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-bugs