[Top][All Lists]

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

Re: ABI problems in ncurses-5.5

From: Thomas Dickey
Subject: Re: ABI problems in ncurses-5.5
Date: Sat, 20 May 2006 10:27:41 -0400
User-agent: Mutt/1.5.9i

On Fri, May 19, 2006 at 11:55:07AM +0400, Stanislav Ievlev wrote:
> Greetings!
> First of all, 
> ncurses-5.5 is binary incompatible with ncurses-5.4 on x86_64 plathform,
> because a new algorithm in configure script chooses unsigned int (4 bytes)
> instead of unsigned long (8 bytes) (was in previous version).

It's a configure-script option, defaulting to the preferred (non-wasteful)
setting.  Packagers who have to maintain compatibility can do so easily;
other people can use the type as it was originally intended (large enough
to hold a narrow character with video-attributes).
> Second problem is in the internal screen structure.
> tinfo and tinfow libraries are binary incompatible again.
> A _screen_acs_fix field (wrapped with ifdefs for WIDEC)
> not at the end of the structure , and , therefore,
> offset of _screen_acs_map is different between these libraries.
> Could you move _screen_acs_fix to the end of the struct?

done (today's patch).
> Third potential problem is the acs_map symbol in tinfo library.
> It's not a good idea to export acs_map as an array.You will have
> a problems, if you change ACS_LEN value. It's better export acs_map as a 
> pointer to chtype array.

ok.  It's unlikely that I'll change ACS_LEN (since it addresses narrow
character-set functionality that).  But from a design viewpoint, it's
> Forth:
> It's not a good idea to define preprocessor macros in headers. It can
> breaks user's code. 
> If you want to support a some legacy compillers, it's better to create
> new configure switch to select generation between inlines or macros.

hmm - there are a lot of define's in ncurses's headers.  Can you be more
specific?  Perhaps you're referring to this:


which I regarded as relatively harmless (using the configure-script's
substitutions to add a name specific to ncurses in curses.h rather than
add a new file to hold substitutions for internal use).  It's only referenced

Since I'd been sticking to the rule of adding ncurses-specific names
as "NCURSES_XXX" or "_ncu_XXX", it didn't seem likely to break anything
that took that rule into account.

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

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