This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: language option segfault



  In message <35B50C41.6256@tssc.co.nz>you write:
  > Jeffrey A Law wrote:
  > > 
  > >   In message <35AEC28A.5535@tssc.co.nz>you write:
  > >   > (I think I have a merge of mainline and 1.1 branches)
  > > I don't understand what you're trying to say.
  > 
  > Taht I'm not sure which branch the problem was in.
Well, what version of the compiler are you using?  It is possible
for us to map from a version # to what sources you are using.
reporting a bug

  > > What specifically are you trying to fix?  ie, what command would I
  > > have to issue to get this core dump?
  > 
  > cc1 (and possibly the others) would die on startup. `./xgcc -B./ foo.c'
  > is sufficient to generated the core dump.
I have not seen this behavior, and I do not see how your change could
prevent a core dump


  > It wasn't the argument that was null, but the long-option string in the
  > internal table that was null (a null pointer is used as a separator
  > between language specific options).
?

Before your patch:
      for (j = NUM_ELEM (documented_lang_options); j--;)
        if (check_lang_option (argv[i], documented_lang_options[j].option))
          break;

After your patch:

      for (j = NUM_ELEM (documented_lang_options); j--;)
      if (documented_lang_options[j].option &&
          check_lang_option (argv[i], documented_lang_options[j].option))
        break;

If "documented_lang_options[j].option" was NULL, then the original code
would pass NULL to "check_lang_option", which would return zero.

With your patch we simply do not call check_lang_option, but you still
have to load the value of documented_lang_options[j].option.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]