Loading ...
Sorry, an error occurred while loading the content.
 

Re: Long lines result in VAX C debugger problems.

Expand Messages
  • Jim Agnew - Department of Neurosurgery,
    Dear All, Walter is right, I was running in a multi-pane debugger, and was assuming he was familiar with the vms debugger. (sorry guys...) I am rebuilding the
    Message 1 of 7 , Nov 7, 2003
      Dear All,

      Walter is right, I was running in a multi-pane debugger, and was
      assuming he was familiar with the vms debugger. (sorry guys...)

      I am rebuilding the vim with the deathtrap call commented out.

      (c *is*

      code; code; /*comment*/ code; code;

      , right???)

      jim


      Bram Moolenaar wrote:

      > Walter Briscoe wrote:
      >
      >
      >>I am continuing to try to get vim working for Jim. Vim fails for him
      >>with a "bus error" or "access violation" or "segmentation fault". Vim's
      >>signal handling means that the usual VMS stack traceback report is not
      >>produced.
      >>
      >>Can deathtrap() in os_unix.c, after dealing with a failure, be changed
      >>to raise the failing signal? In unix, it would also be nice to save the
      >>failure.
      >
      >
      > This already happens, in may_core_dump(). But some systems can't deal
      > with signals inside signal handling functions.
      >
      > If you don't want Vim to catch deadly signals for debugging reasons,
      > comment-out the line in os_unix.c that makes deathtrap being invoked:
      >
      > catch_signals(deathtrap, SIG_ERR);
      >
      >
      >
      >>Jim's problem happen's in clear_termoptions(). He gets the following
      >>behavior in the debugger:
      >>! 35400: clear_termoptions(); /* clear old options */
      >>Step/Into
      >>!%DEBUG-I-DYNMODSET, setting module OPTION
      >>!stepped to routine OPTION\clear_termoptions
      >>!%DEBUG-W-UNAREASRC, unable to read source file BAYER$DKB100:[VIM.VIM62-106.SRC]OPTION.C;1
      >>!-RMS-W-RTB, 289 byte record too large for user's buffer
      >>Step
      >>!stepped to OPTION\clear_termoptions\%LINE 41035
      >>! 41035: for (opt_idx = 0; (str = get_key_name(opt_idx)) != NULL; opt
      >>! -: _idx++)
      >
      >
      > Note that this is wrong, this line does not appear in
      > clear_termoptions() but in ExpandSettings().
      >
      >
      >>The long record destroys the validity of the code reporting the current
      >>location. The 289 byte record is option.c(1055). I think the constraint
      >>is probably 255. Can Jim supply the correct value.?
      >>Meanwhile, I want to know, is string constant concatenation sufficiently
      >>portable for Vim's purposes. e.g. can we rewrite char *a = "foo"; as
      >>char *a = "f"
      >> "oo";
      >>?
      >
      >
      > Older compilers don't support string concatenation.
      >
      >
      >>option.h(277) is a 770 byte line. I did not report this as a problem in
      >>the past because I was able to work around it. (PC-Lint's default line
      >>length limit - I think of 512 bytes - is easy to work around it ;-)
      >>ISTR C89 has a 509 character line limit of 509 (512 less "\r\n\0" ? )
      >
      >
      > I have not heard about a line length limit for C compilers before. That
      > is a weird restriction.
      >
      > For this compiler we could disable the Lisp function, that should work
      > around the problem.
      >
      >
      >>Many work with 80 byte screen lines; I work with 140.
      >>There are 27 lines longer than 140 bytes and 596 longer than 80.
      >>Does Bram object to my using \ and string concatenation to hit those 27?
      >>596 is too big a problem and 80 an unreasonable council of perfection.
      >>132/31 would make all lines printable on a traditional printer.
      >
      >
      > I always try to make lines fit in a 80 character screen. The places
      > where this isn't done are either mistakes or where a string should not
      > be broken. Using "\" concatenation is generally considered dangerous.
      > Some compilers generate warnings for this.
      >

      --
      "3,000 years ago I made a mistake." Elrond Half-Elven, in "Fellowship
      of the Ring"

      "I try not to be right any more than necessary". -- Larry Wall, author
      of the Perl Language
    • Bram Moolenaar
      Walter Briscoe wrote: Since it has taken so long to run into this problem it seems that very few compilers have a problem with long lines. ... Do you mean that
      Message 2 of 7 , Nov 7, 2003
        Walter Briscoe wrote:

        Since it has taken so long to run into this problem it seems that very
        few compilers have a problem with long lines.

        > >For this compiler we could disable the Lisp function, that should work
        > >around the problem.
        > I don't think so. The problem is that a source line is longer than 255
        > bytes. In the dim and distant past, I worked on VaxC symbol display and
        > that is my hazy memory. Can Jim check?

        Do you mean that when you put a long line in between "#ifdef asdf" and
        "#endif" the compiler will still refuse to compile the file?

        > This does not work for the other 2 long strings. We could split the
        > definitions into chunks and load the data in option.c. I don't like
        > doing that as it requires the programmer to do more work. However, it
        > does seem it will work and fit all constraints. What does Bram think?

        I don't like making the code more difficult for a rare compiler. But if
        this code prevents people from using Vim on a specific platform, I could
        include a patch that fixes this (if it's tested).

        --
        Why I like vim:
        > I like VIM because, when I ask a question in this newsgroup, I get a
        > one-line answer. With xemacs, I get a 1Kb lisp script with bugs in it ;-)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
      • Walter Briscoe
        In message of Fri, 7 Nov 2003 16:41:52 in , Bram Moolenaar writes ... The problem is in the
        Message 3 of 7 , Nov 7, 2003
          In message <200311071541.hA7FfqZX007747@...> of Fri, 7 Nov
          2003 16:41:52 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >Since it has taken so long to run into this problem it seems that very
          >few compilers have a problem with long lines.
          The problem is in the debugger rather than the compiler. I doubt if 1 in
          100 vim users run vim through their debugger.

          >
          >> >For this compiler we could disable the Lisp function, that should work
          >> >around the problem.
          >> I don't think so. The problem is that a source line is longer than 255
          >> bytes. In the dim and distant past, I worked on VaxC symbol display and
          >> that is my hazy memory. Can Jim check?
          >
          >Do you mean that when you put a long line in between "#ifdef asdf" and
          >"#endif" the compiler will still refuse to compile the file?
          No! The code compiles happily. The debugger can't handle it.
          It is a long time ago. Jim can confirm or contradict what Bram and I
          expect to happen.

          >
          >> This does not work for the other 2 long strings. We could split the
          >> definitions into chunks and load the data in option.c. I don't like
          >> doing that as it requires the programmer to do more work. However, it
          >> does seem it will work and fit all constraints. What does Bram think?
          >
          >I don't like making the code more difficult for a rare compiler. But if
          >this code prevents people from using Vim on a specific platform, I could
          >include a patch that fixes this (if it's tested).
          >
          I intend to eliminate long lines to deal with the vagaries of a rare
          compiler. Like Bram, I don't have that compiler. I do have others and
          will obviously put any proposed patch through those before submitting
          it. I will check the fix works for me. I will also get Jim to confirm it
          hits his problem. I can do no more. Watch this space ;-)
          --
          Walter Briscoe
        Your message has been successfully submitted and would be delivered to recipients shortly.