[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
better.
> 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:
#ifndef NCURSES_INLINE
#define NCURSES_INLINE @NCURSES_INLINE@
#endif
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
internally...
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>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature