From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: The most recent ncurses spec changelog entry, * Fri May 23 2003 Adrian Havill <havill> 5.3-5 - added latest rollup patch with widec/UTF8 centric weekly (20030517) - added --enable-widec to configure (#86311) gives reason to believe this change is the source of why "centericq" (see URL for a src.rpm for Red Hat Linux), which works flawlessly on Red Hat Linux 9, has misplaced/corrupted buttons on Red Hat Linux 9.0.93. What is more likely? That above change has a bug? Or that centericq needs adjustment for above change? Version-Release number of selected component (if applicable): 5.3-5 How reproducible: Always Steps to Reproduce: 1. Rebuild centericq-4.9.4-0.fdr.2.rh90.src.rpm on Severn. 2. Run centericq in virtual console or X terminal. Notice corrupted buttons on startup screen.
the problem could be the addition of the rollup patch, but it should not be due to --enable-widec. You should need to explictly link to the wide version of the functions to get them. Does the error appear when installing the binary built on a system that doesn't have a widec enabled ncurses, or when using a binary rebuilt on a RHL 9 w/ncursesw machine?
Test 1: - platform: Severn - ncurses: 5.3-5 - centericq: built on Shrike with ncurses-5.3-4 => same symptoms Test 2: - platform: Shrike - ncurses: 5.3-5 (rebuilt Severn's src.rpm on Shrike) - centericq: built on Shrike with ncurses-5.3-4 => same symptoms Test 3: - platform: Shrike - ncurses: 5.3-5 (rebuilt Severn's src.rpm on Shrike) - centericq: rebuilt with ncurses-5.3-5 => same symptoms Conclusively, as soon as ncurses is upgraded to 5.3-5, centericq looks bad, regardless of whether it was built with 5.3-4 or 5.3-5.
Thomas, the info above seems to suggest the problem is in the rollup, not in the --enable-widec. Is this a known problem?
Nothing comes to mind: there are a few fixes that apply to the normal ncurses library (workarounds for line-drawing in screen and Linux console), but the only breakage I recall has been short-term from work on the wide-character code (and none of the breaks & subsequent fixes occur around the rollup). The screenshot from centericq's webpage shows it uses line-drawing. Perhaps there was some workaround for Redhat 8/9 which doesn't work any more. I'm not sure what - the 20030517 rollup has the most recent fix in this area.
Created attachment 93508 [details] screenshot good screenshot of centericq start screen with ncurses 5.3-4 (no errors)
Created attachment 93509 [details] screenshot bad screenshot of centericq start screen with ncurses 5.3-5 (errors)
Created attachment 93510 [details] screenshot bad / next screen next screen of centericq is also bad in several places (ncurses 5.3-5)
I built a copy of current centericq & current ncurses on Debian 3.0r1 last night, ran with both POSIX and en_US.UTF-8 locales and did not see anything like that. (I'll take a look on one of my Redhat installs to see if I can reproduce it, but the picture doesn't look like any of the bugs I've seen recently).
Built cenrtericq 4.9.4, linked to ncurses 5.3 20030517 on Redhat 9, run in xterm and uxterm, seeing no problem. Since I don't know where to find the rpm for ncurses "5.3-5", I can't look for breakage in that (or conversely, in the centericq package). It's also possible that terminal settings or locale are related, but this report has no relevant information.
ncurses-5.3-5 is included within Red Hat Linux 9.0.93 Public Beta (Severn), e.g. here: http://redhat.newaol.com/pub/redhat/linux/beta/severn/en/os/i386/SRPMS/ncurses-5.3-5.src.rpm
That's better (I can see a problem, and will have to see where it comes from).
Created attachment 93543 [details] bug fix
The bug is that an empty format to safe_sprintf will make it return a null pointer -- but only for the case where the --enable-safe-sprintf option is chosen. That was introduced in a fix for memory leak. The attached fix is what I'll add for my patch tomorrow. (Returning a null pointer in turn makes printw return an error, and probably centericq was using that, e.g., in a mvprintw, etc.
I'd like to confirm that the fix works for me and therefore I reopen the bug until it's fixed in Red Hat's package, too.
off-by-one fixes included in release 7 (in rawhide)