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

Re: Long lines result in VAX C debugger problems.

Expand Messages
  • Walter Briscoe
    In message of Fri, 7 Nov 2003 14:09:39 in , Bram Moolenaar writes ... OK? Jim! ... That is the
    Message 1 of 7 , Nov 7, 2003
      In message <200311071309.hA7D9dHn005180@...> of Fri, 7 Nov
      2003 14:09:39 in , Bram Moolenaar <Bram@...> writes
      >
      >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);
      OK? Jim!

      >
      >
      >> 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.VIM
      >> !62-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().

      That is the consequence of my words below.

      >
      >> 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.
      C89 does not support lines of more than 509 bytes.

      5.2.4 Environmental limits

      Both the translation and execution environments
      constrain the implementation of language translators and
      libraries. The following summarizes the environmental
      limits on a conforming implementation.

      5.2.4.1 Translation limits

      The implementation shall be able to translate and
      execute at least one program that contains at least one
      instance of every one of the following limits:8
      ...

      __________

      8. Implementations should avoid imposing fixed translation
      limits whenever possible.


      - 509 characters in a logical source line

      - 509 characters in a character string literal or wide
      string literal (after concatenation)

      The corresponding C99 figure is 4095.

      >
      >> 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.
      See what I wrote already

      >
      >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?

      >
      >> 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.
      >

      Let me see:
      We could have:
      #ifdef VMS$
      # define DFLT_EFM>--"%A%p^,%C%%CC-%t-%m,%Cat line number %l in file %f"
      #else
      # include "dflt_efm.h"
      #endif

      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?
      --
      Walter Briscoe
    • Jim Agnew - Department of Neurosurgery,
      Comments interspersed... ... I ll try that... ... I think so. the too long line compiles ok with the C compiler, but when the debugger slurps the source into
      Message 2 of 7 , Nov 7, 2003
        Comments interspersed...

        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);
        >
        >

        I'll try that...

        >
        >>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().
        >

        I think so. the too long line compiles ok with the C compiler, but when
        the debugger slurps the source into it, it chokes. Now that I know
        you want a traceback report, I'll try to get one out..

        >
        >>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.
        >

        Best to make vim work for everybody. this too long line does compile.

        >
        >>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
      • 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 3 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 4 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 5 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.