lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV the printing function and submit/image/reset buttons


From: Klaus Weide
Subject: Re: LYNX-DEV the printing function and submit/image/reset buttons
Date: Wed, 9 Apr 1997 18:28:02 -0500 (CDT)

On Tue, 8 Apr 1997, Laura Eaves wrote:

> > From: Klaus Weide <address@hidden>
> >...
> > I haven't looked at your code in detail or tested it.
> > So I cannot say whether your patch creates problems (I just supect
> > it may, given how complicated that FORM-handling stuff is...)
> > Just some quick comments:
[code snipped]
> >
> > Have you checked whether your code handles e.g. submit fields, possibly
> > with a long value lable, adequately when within a PRE section... ?
> 
> I'm not sure what the code for HTML_PRE is trying to do...
> It seems it indiscriminantly puts out 20 '_'s and subtracts this amount
> from chars without checking the value of chars.  If chars is still > 0,
> the subsequent code then puts out the "rest" of the '_'s in the field.
> 
> How should this apply to submit/reset button values?  Should I force them
> to be a minimum of 20 chars?  Does that mean I should append '_'s if the
> value if chars < 20?
>
> I guess I just chose to ignore HTML_PRE until I had more info...
> What do you think?

I haven't really tried to understand all that form related stuff;
I was just mentioning some things that I thought of when I looked
at your diffs (since you asked for comments :) ).

But what I think is that you should probably test it, and see how it
behaves in different situations.  Say an INPUT field within PRE which
has text (given by VALUE attribute?) which is longert than 20
characters...
 
> > >               }
> > > !             /*--LE*/
> > > !             if ( !is_submit_or_reset ) {
> > > !                 for (; chars > 0; chars--)
> > > !                     HTML_put_character(me, '_');
> > > !             } else { int i;
> > > !                 for ( i = 0;  i < chars;  ++i )
> >                                   ^^^^^^^^^^
> > > !                     HTML_put_character(me, I.value[i]);
> > > !             }
> > >               HText_setIgnoreExcess(me->text, FALSE);
> > >           }
> > >           break;
> >
> > You should probably test for end of string (a '\0' char) there,
> > or explain why that is not necessary.
> 
> chars is returned from HText_beginInput and is the length
> of the value.  I.value for submit buttons
> is also processed in HText_beginInput and presumably is legal...
> In any case, chars should be no longer than strlen(I.value).  So I don't think
> there's a null in the first 'chars' chars of I.value.

HText_beginInput() looks complicated enough that I wouldn't trust it to
always do what I think it would do...  But maybe you understand it better,
and/or have looked at it longer, or are just more brave :)

Anyway I noticed that in all other places in HTML.c where the return value
of HText_beginInput() is used, it is just used as a counter for generating
sequences of '_' chars, not as a string length which is relied on.
There is also the basic question: if it is as simple as your change seems
to be, why hasn't it been done before?  Makes me think that there *may*
be a good reason for it.  Maybe Fote can clarify.

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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