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

Long lines result in VAX C debugger problems.

Expand Messages
  • Walter Briscoe
    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
    Message 1 of 7 , Nov 7, 2003
    • 0 Attachment
      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.

      I am unable to do this as I don't have access to any variety of UNIX.
      I used to have KNOPPIX; that does not support write access to NTFS
      partitions; I recently saved 2 Gb in 16 by converting from FAT32 to
      NTFS; NTFS is both proprietary and secret. open source drivers which
      write to NTFS drives tend to trash the partition.

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

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

      C:\wfb\vim\bld\vim62\src) grep -n ".\{255,\}" *.h *.c
      option.h:41:#define DFLT_EFM "%*[^\"]\"%f\"%*\\D%l: %m,\"%f\"% ...
      option.h:277:#define LISPWORD_VALUE "defun,define,defmacro,se ...
      option.c:1055: {(char_u *)"8:SpecialKey,@:No ...

      C:\wfb\vim\bld\vim62\src)

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

      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 will have to apply all the other patches first! ;-)

      (When my daughter does some more statistics in her maths (Americans use
      math) AS level - exam taken in the penultimate English school year, I
      may ask her to model the line length distribution. A Poisson
      distribution might fit ;-) In a W2K cmd.exe where I do not have wc on my
      path, I got the cumulative totals, ignoring the effect of tabs, with
      for /l %l in (0,1,300) do grep ".\{%l,\}" *.h *.c | sed -n $=
      I did not measure my impression that my sed implementation's timing was
      sensitive to the volume of data. )
      --
      Walter Briscoe
    • Bram Moolenaar
      ... 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
      Message 2 of 7 , Nov 7, 2003
      • 0 Attachment
        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.

        --
        THEOREM: VI is perfect.
        PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are
        1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect.
        QED
        -- Arthur Tateishi

        /// 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 14:09:39 in , Bram Moolenaar writes ... OK? Jim! ... That is the
        Message 3 of 7 , Nov 7, 2003
        • 0 Attachment
          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 4 of 7 , Nov 7, 2003
          • 0 Attachment
            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 5 of 7 , Nov 7, 2003
            • 0 Attachment
              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 6 of 7 , Nov 7, 2003
              • 0 Attachment
                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 7 of 7 , Nov 7, 2003
                • 0 Attachment
                  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.