wresize and maxx/maxy short int overflow

[Katarina Machalkova-3]

Hello, list,

Following is the code snippet:

{
   WINDOW *w
    ...
    LOG << "One: " << w->_maxy << " " << w->_maxx << endl;
    int ret = ::wresize( w, lines, columns );
    LOG << "Two: " << w->_maxy << " " << w->_maxx << endl;
}

maxy/maxx are short ints (NCURSES_SIZE_T, to be more precise), while wresize()
takes "normal" ints as params. Now I'm trying to make the window really big in
Y dimension by setting 'lines' param to value greater than 32 768.

The above prints:
One: 3 22
Two: -22207 22

Is this bug in a sense that maxy (maxx respectively) should never become
negative,  or is it responsibility of the application calling wresize to make
sure its params are always in range of short ints and overflow of maxy/maxx
never occurs?

Thanks for advice (it's likely PEBCAK what I'm seeing but I'd rather be sure)

hB.
--
  \\\\\              Katarina Machalkova    
  \\\\\\\__o          YaST developer
__\\\\\\\'/_          & hedgehog painter


_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@...
http://lists.gnu.org/mailman/listinfo/bug-ncurses

[Stephan Beal-3]

On Mon, Nov 2, 2009 at 3:29 PM, Katarina Machalkova <kmachalkova@...> wrote:

maxy/maxx are short ints (NCURSES_SIZE_T, to be more precise), while wresize()
takes "normal" ints as params. Now I'm trying to make the window really big in
Y dimension by setting 'lines' param to value greater than 32 768.

Hi Katarina!

It is an error to create a WINDOW object larger than the screen. PAD objects may be larger, but WINDOWs cannot (if i'm not mistaken). Looking at the man pages, i cannot find this documented, but i "seem to remember" reading it somewhere. In fact, the X/Open standard defines _no_ error conditions for newwin() (which is really dumb, IMO). The man pages do say:

---------

Special windows called pads may also be manipulated.  These are windows which are not constrained  to  the  size  of  the screen and whose contents need not be completely displayed.  See pad(3NCURSES) for more information.

---------

which implies that WINDOWs may not be larger than the screen.

 

The above prints:
One: 3 22
Two: -22207 22

A quick look at the PAD API (man pad) shows that those functions do take "int" arguments.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@...
http://lists.gnu.org/mailman/listinfo/bug-ncurses

[Thomas Dickey-2]

On Mon, 2 Nov 2009, Katarina Machalkova wrote:

> Hello, list,
>
> Following is the code snippet:
>
> {
>   WINDOW *w
>    ...
>    LOG << "One: " << w->_maxy << " " << w->_maxx << endl;
>    int ret = ::wresize( w, lines, columns );
>    LOG << "Two: " << w->_maxy << " " << w->_maxx << endl;
> }
>
> maxy/maxx are short ints (NCURSES_SIZE_T, to be more precise), while wresize()
> takes "normal" ints as params. Now I'm trying to make the window really big in
> Y dimension by setting 'lines' param to value greater than 32 768.

NCURSES_SIZE_T is a signed short just because of binary compatibility...

I can improve this specific case by returning an error if the parameters
go out of bounds (there are some others of course).

> The above prints:
> One: 3 22
> Two: -22207 22
>
> Is this bug in a sense that maxy (maxx respectively) should never become
> negative,  or is it responsibility of the application calling wresize to make
> sure its params are always in range of short ints and overflow of maxy/maxx
> never occurs?

generally the library "should" check its parameters.

(I recall some discussion - xorg is recent - from developers who
insist that libraries shouldn't do this ;-)

> Thanks for advice (it's likely PEBCAK what I'm seeing but I'd rather be sure)
>
> hB.
> --
>  \\\\\              Katarina Machalkova
>  \\\\\\\__o          YaST developer
> __\\\\\\\'/_          & hedgehog painter
>
>
> _______________________________________________
> Bug-ncurses mailing list
> Bug-ncurses@...
> http://lists.gnu.org/mailman/listinfo/bug-ncurses
>

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@...
http://lists.gnu.org/mailman/listinfo/bug-ncurses

[Katarina Machalkova-3]

Hi,

> > maxy/maxx are short ints (NCURSES_SIZE_T, to be more precise), while
> > wresize()
> > takes "normal" ints as params. Now I'm trying to make the window really
> > big in
> > Y dimension by setting 'lines' param to value greater than 32 768.
>
> Hi Katarina!
>
> It is an error to create a WINDOW object larger than the screen. PAD
> objects may be larger, but WINDOWs cannot (if i'm not mistaken)

I wrote "window", but I meant "pad", grrr :) it's created using newpad().

So - can I safely (i.e. without maxx/maxy running beyond limits) create a pad
with more than 32 768 lines? Can I resize existing pad to more than 32 768
lines?

If the answer to the above question is negative, how can have ncurses display
a list with many ( > 50k ) entries?

Current implementation (which I inherited from the previous maintainer) is
that initially a default size pad is created, it is resized to accomodate all
the items, and as the user moves cursor keys, corresponding parts of that big
pad are copied (copywin()) to the screen.

hB.
--
  \\\\\              Katarina Machalkova    
  \\\\\\\__o          YaST developer
__\\\\\\\'/_          & hedgehog painter


_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@...
http://lists.gnu.org/mailman/listinfo/bug-ncurses

[Thomas Dickey-2]

On Tue, 3 Nov 2009, Katarina Machalkova wrote:

> Hi,
>
>>> maxy/maxx are short ints (NCURSES_SIZE_T, to be more precise), while
>>> wresize()
>>> takes "normal" ints as params. Now I'm trying to make the window really
>>> big in
>>> Y dimension by setting 'lines' param to value greater than 32 768.
>>
>> Hi Katarina!
>>
>> It is an error to create a WINDOW object larger than the screen. PAD
>> objects may be larger, but WINDOWs cannot (if i'm not mistaken)
>
> I wrote "window", but I meant "pad", grrr :) it's created using newpad().
>
> So - can I safely (i.e. without maxx/maxy running beyond limits) create a pad
> with more than 32 768 lines? Can I resize existing pad to more than 32 768
> lines?

no: signed shorts are used to store cursor position and window/pad
limits.  That's been a visible part of the window struct "forever".

If you happen to be building/using a variant configuration of ncurses
that uses the NCURSES_OPAQUE feature, you can change NCURSES_SIZE_T
to an int.  That's done as a side-effect of --enable-reentrant for
example.

> If the answer to the above question is negative, how can have ncurses display
> a list with many ( > 50k ) entries?

The application maintains the list, and pages it in/out of the pad (or
window) as needed.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@...
http://lists.gnu.org/mailman/listinfo/bug-ncurses