lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Forms Word Wrap Problem with Lynx


From: Kim DeVaughn
Subject: Re: lynx-dev Forms Word Wrap Problem with Lynx
Date: Fri, 23 Jul 1999 11:57:46 -0600

On Fri, Jul 23, 1999, Klaus Weide (address@hidden) said:
|
| > The external editing code (as well as the insert file code) does no
| > checking for edited lines that exceed MAX_LINE (which is the def used
| > for the HTLine structs).
|
| Different topic; MAX_LINE != "MAXLENGTH".

Yeah, I know that.  And indeed, fiddling MAXLENGTH as you suggest may
well be made to work for manual input into a TEXTAREA.  It would have
no effect on externally entered data though (either via an editor, or
an inserted file).

My point was that trying a similar strategy with MAX_LINE will not work
for those entry methods either.


| > Such checking *could* be added, of course, and excessively long lines
|
| It *should*. :)

Probably so.


| > broken/truncated/ignored/rejected/whatever, but since the define for
| > MAX_LINE says:
| >
| >   #define MAX_LINE 1024    /* Hope that no window is larger than this */
| >                               ^^^^
| >
| > and since I didn't really see HTLines being checked elsewhere for exceeding
| > the MAX_LINE value, and for performance reasons, I didn't do any checking
| > either.
|
| The only way lines can grow or be added used to be HText_appendCharacter
| and split_line, and the code there makes sure that lines never can grow
| too long (assuming it all works, give or take a few...).

Perhaps ... :-) ...


| But any new way of adding lines *really* should check for MAX_LINE.
| (According to what you write about not checking, I guess trying to insert
| a binary file into a textarea would likely crash lynx, but haven't tried
| it.)

Quite likely (for an arbitrary binary that is larger than MAX_LINE bytes
[where "arbitrary" here means having a run of consecutive bytes that do
not include the binary equivalent of a \n char, for the particular target
platform/OS]).

Something about "getting one's just rewards".  :-)


| In my reading, the "hope" is about whether the fixed value is large enough
| to allow using the full width of windows, not about wehether it is big
| enough to "usually" avoid crashes.

I read it the other way, given that the default value (1024) is considerably
larger than any screen/display/window width of any terminal I know of.  Had
the value been ~256, or ~384, or some such, I would probably have read it
the way you did.


Having said all that (and removing tongue from cheek, now), I agree that
such input should be checked for possible buffer overflow.

Since there are a couple other "cleanup things" that I've been meaning to
get around to doing to the TEXTAREA edit code, I'll add that one to my list.

I suppose the question is what to do in overflow case.

My inclination is to summarily wrap the overflow to a new line at that
point, and *perhaps* throw up a message in the statusline that one or more
lines were too long, but were wrapped at an arbitrary point (ie, no text
lost, but format may be altered).

Given the default (1024) line length, I can't see trying to do more than
that.

/kim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]