make-string uninitialized memory eposure considered harmful

[Greg Troxel]

In guile 1.6, NetBSD 1.6-stable/i386, I found that make-string returns
random stuff if you don't give it a second arg.  

guile> (make-string 100)
"traced-stack-ids set of stack ids for which tracing is active. executable is 
in no way restricted"

This I took to be a sign of brokenness.  So I read the docs:

guile> (help make-string)
`make-string' is a primitive procedure in the (guile) module.

 - Scheme Procedure: make-string k [chr]
     Return a newly allocated string of length K.  If CHR is given,
     then all elements of the string are initialized to CHR, otherwise
     the contents of the STRING are unspecified.

 
and tried again.

guile> (make-string 1000)
"make-stack

 - Scheme Procedure: make-stack obj . args
     Create a new stack. If OBJ is `#t', the current evaluation stack
     is used for creating the stack frames, otherwise the frames are
     taken from OBJ (which must be either a debug object or a
     continuation).

     ARGS should be a list containing any combination of integer,
     procedure and `#t' values.

     These values specify various ways of cutting away uninteresting
     stack frames from the top and bottom of the stack that
     `make-stack' returns.  They come in pairs like this: `(INNER_CUT_1
     OUTER_CUT_1 INNER_CUT_2 OUTER_CUT_2 ...)'.

     Each INNER_CUT_N can be `#t', an integer, or a procedure.  `#t'
     means to cut away all frames up to but excluding the first user
     module frame.  An integer means to cut away exactly that number of
     frames.  A procedure means to cut away all frames up to but
     excluding the application frame whose procedure matches the
     specified one.

     Each OUT"

At this point, I get what is going on.  This is confusing, and exposes
the contents of random memory locations, perhaps exposing a password
that somone thought had been garbage collected.  So, I'd argue that
the default behavior should be to fill with nulls, or something, even
though the spec should remain unspecified.  If we are afraid people
will depend on that, it can fill with something chosen arbitrarily,
but it shouldn't expose the existing contents of free memory.

Anyone want to call me paranoid?