[Vm-dev] sqUnixExternalPrims.c tryLoading()

David T. Lewis lewis at mail.msen.com
Mon Aug 10 22:27:49 UTC 2015

On Mon, Aug 10, 2015 at 10:53:50AM -0700, John McIntosh wrote:
> On Mon, Aug 10, 2015 at 10:46 AM, tim Rowledge <tim at rowledge.org> wrote:
> >
> > The bits after the \000  *shouldn???t* matter a damn to any C code unless
> > possibly something is carefully using a length-specifying copy with the
> > wrong length. $15 showing with all the follow-on trash seems odd but pretty
> > much everything about gdb puzzles me.
> >
> Assuming $15 is being shown as a 1K memory dump, versus a C String then it
> would be proper to dump the ascii values and then octal values for
> none-printables.  In this case the libName would be /home/ooplu/Desktop/Cog_
> build2/products/coglinuxht/lib/squeak/4.0-3256/vm
> -display-X11  as you terminate on the octal \000  However are you sure the
> parm being passed is a cString, or is it a Smalltalk string and you are
> just seeing the object space after the -X11.  This of course would be
> incorrect and lucky if the trailing byte is \000

It's nothing to worry about one way or the other. libName is a local variable
in a function in the platform code. It is an array of char, large enough to
do whatever it needs to do. Anything after the null terminator (for the C
string) is of no interest so long as we do not overwrite the length of that
array (which we do not). It might contain left over data (the variable is
declared within the scope of a loop) or it might be just uninitialized junk.
Either way it's just some extra bytes that do not affect the code.

The debugger might display this data in various ways, but it's really just
an array of 8 bit bytes that are being interpreted as an null-terminated
string in the C tradition.


More information about the Vm-dev mailing list