cvs commit: src/lib/libc/locale utf8.c

[Bruce Evans]

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