Re: Long lines result in VAX C debugger problems.
- 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.
code; code; /*comment*/ code; code;
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
>>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
> 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 */
>>!%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
>>!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"
> 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
- 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 workDo you mean that when you put a long line in between "#ifdef asdf" and
> >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?
"#endif" the compiler will still refuse to compile the file?
> This does not work for the other 2 long strings. We could split theI don't like making the code more difficult for a rare compiler. But if
> 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?
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/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
> one-line answer. With xemacs, I get a 1Kb lisp script with bugs in it ;-)
/// 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 ///
- In message <200311071541.hA7FfqZX007747@...> of Fri, 7 Nov
2003 16:41:52 in , Bram Moolenaar <Bram@...> writes
>The problem is in the debugger rather than the compiler. I doubt if 1 in
>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.
100 vim users run vim through their debugger.
>No! The code compiles happily. The debugger can't handle it.
>> >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?
It is a long time ago. Jim can confirm or contradict what Bram and I
expect to happen.
>I intend to eliminate long lines to deal with the vagaries of a rare
>> 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).
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 ;-)