Date: Wed, 31 Oct 2007 21:41:13 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: d@delphij.net Cc: Andrey Chernov <ache@nagual.pp.ru>, Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/locale utf8.c Message-ID: <20071031205412.U3526@delplex.bde.org> In-Reply-To: <4720E904.2090704@delphij.net> References: <200710150951.l9F9pUm7026506@repoman.freebsd.org> <4720B30F.4040903@samsco.org> <20071025151707.GA11398@nagual.pp.ru> <4720E0AF.1010004@samsco.org> <4720E904.2090704@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Oct 2007, LI Xin wrote:
> Scott Long wrote:
>> Andrey Chernov wrote:
>>> On Thu, Oct 25, 2007 at 09:15:27AM -0600, Scott Long wrote:
>>>> Andrey A. Chernov wrote:
>>>>> ache 2007-10-15 09:51:30 UTC
>>>>> FreeBSD src repository
>>>>> Modified files:
>>>>> lib/libc/locale utf8.c Log:
>>>>> Add comment explaining __mb_sb_limit trick here.
>>>>> Revision Changes Path
>>>>> 1.16 +5 -0 src/lib/libc/locale/utf8.c
>>>> When is the ABI damage from this going to be fixed?
>>>
>>> There is no ABI damage in -current.
>>
>> Exposing the __mb_sb_limit symbol has instantly created a need
>> to have a compat7x package, and is causing many users problems
>> during upgrades and normal operations. It may not be a problem
>> for you, Andre, but it's a problem for everyone else. Please
>> respect this and fix it.
>
> Well, I think the problem is not exposing a new symbol by itself, but
> __mb_sb_limit is being used in _ctype.h, in a form of __inline
> functions. Therefore, the change will break new binaries running on
> older systems. Personally I think this is acceptable, but maybe we
> could have a better way to avoid this, because the binaries are no
> longer backward compatible (i.e. you may have trouble running a program
> compiled for 6.3-RELEASE on 6.2-RELEASE, if it uses locale bits).
I used to think that using inline functions reduced ABI/API problems.
Now I know that it increases them. Inline functions may or may not
actually be inlined (and they usually won't be if the application is
compiled with -O0), so using them gives all the problems of non-inline
functions, plus the problems of determining how much of the ABI they
expose and making the exposed ABI official. The amount of exposure
depends on the user's ${CFLAGS}, so determining it is difficult. It
is probably necessary to make all symbols referenced in all inline
functions part of the ABI.
__mb_sb_limit is extern int, so the ABI breakage was obvious. If it
had been a compile-time constant with the usual ${CFLAGS} but not a
constant with -O0, of if the constant depended on ${CFLAGS} or changed
with __FreeBSD_version, then the problem would have been less obvious.
Now the limit is spelled 128, so it really is constant and won't cause
problems unless the constant changes.
_ctype.h still declares __mb_sb_limit but now doesn't use it.
__mb_sb_limit was and is declared as extern in too many files in
libc/locale. The extern in _ctype.h probably gives redundant declarations.
__mb_sb_limit is still initialized in many files in libc/locale. These
initializations now seem to be unused. Some of them are to 256, so why
is the constant only 128?
__mb_sb_limit is still in Symbol.map. I think this would be needed if
__mb_sb_limit were actually used (since although it is now private to
the library, it would be part of an inter-library ABI if it were used).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071031205412.U3526>