[Top][All Lists]

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

Re: color in subwindows

From: D. Stimits
Subject: Re: color in subwindows
Date: Tue, 17 Jun 2003 16:03:15 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018

Thomas Dickey wrote:

On Tue, Jun 17, 2003 at 01:53:55PM -0600, D. Stimits wrote:

>I found something interesting, on a debug compile. How is the file
>llib-lncurses used? Using the most recent roll-up patch 20030510, and

systems that provide the "lint" program can use that to build a lint-library. I don't use it much for that anymore - only Sun seems to deliver a quasi-working
lint currently - but it's useful for a snapshot of the interfaces provided
by the library.  Most of the file is generated using cproto (there're a
few lines that I edit by hand).

>comparing this file from one I did a debug build on a couple months ago,
>I see that the newest one has const on fmt, but the debug version does
>not (I am not currently linking against the debug version, but the rpm
>for the binary was created from it). That llib-lncurses file seems to be
>the key, as on the older one it has this:
>#undef mvprintw
>int     mvprintw(
>                int     y,
>                int     x,
>                char    *fmt,
>                ...)
>                { return(*(int *)0); }
>On this older one it removes the const version and puts non-const back
>in. I guess what I need is a new rpm based on all of the patches that
>have been out since 5.3, rather than one based on only part of the patches.

I should put an rcs identifier in that file (just so we could agree on which
one you're looking at).  Mine was last touched April 12.  The previous
version was from August 31. The current one has const's for printw because
of the change I made in November.

My most recent build was created by taking the ncurses-5.3 tarball, running patch-5.3-20030510.sh on it, then patching with:

In this version, the lint file does show const char*, but g++ tells me this is non-const and fails with passing of a const char* argument, due to violation of passing const to a non-const argument. I know for a fact that it does not actually alter the fmt argument, the only problem is that in the implementation itself the const is discarded and g++ calls that a hard error (and it should be, const is there for a reason). I am stumped as to how the const is being discarded (my test is on mvwprintw), but I can verify with ldd that I am using the library I am expecting to use, and I can stat the lib and verify that it was replaced by my new version only moments before testing. Perhaps it is related to other "redhatisms" during the creation of the rpm, but I am moderately confident that this is not the case (I can make the generated source rpm or i386 binary rpm available if you wish).

D. Stimits, stimits AT attbi DOT com

reply via email to

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