Re: [patch] Fix a segfault in h8300 port.

[law at redhat dot com]

  In message <879EA880A0FED411996B00B0D0B082EC0D39BF@hxi_exch01.hxi.com>you wri
te:
  > Hi Jeff,
  > 
  > >   > 2001-10-29  Kazu Hirata  <kazu@hxi.com>
  > >   > 
  > >   > 	* config/h8300/h8300.c (h8300_encode_label): Compute a string
  > >   > 	before passing it to ggc_alloc_string.
  > > Err, why do you need to compute the new string before passing it to
  > > ggc_alloc_string.
  > > 
  > > Wouldn't fixing the length of the desired string passed to
  > > ggc_alloc_string fix this problem?
  > 
  > The length of the desired string is correct; it is "strlen (str) + 1",
  > excluding a terminator.
But you have to pass the length including the terminator to ggc_alloc_string.
I assumed that's the underlying bug you're fixing (the old code didn't
include the terminator in the length, which could potentially lead to a 
segfault).

ie, you said you were fixing a segfault, but you really didn't identify
how you were getting the segfault.  That's really the key issue at hand
in my mind.   Why did you get the segfault?

  > Since ggc_alloc_string returns a pointer of const char *, I cannot
  > mess with the pointer in terms of semantics or syntax.  In my
  > understanding, ggc_alloc_string saves memory by not allocating memory
  > for strings that have occured once in the past, so ggc_alloc_string
  > needs to know what the string is.
True, but I would expect that to be independent of avoiding the segfault;
ie, this is a memory consumption optimization.  I would like to hope
that the code deals with being passed an empty string or null pointer.
But then again, maybe it doesn't.

jeff

ps.  FWIW, I doubt there's significant memory savings in this case -- the
number of label encodings we make on the H8 port is usually quite small.
The number of duplicate encodings is even smaller.