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

[ Available lists | Index of cvs-src | Month of Oct 2007 | Week of 25 Oct 2007 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Daniel Eischen <deischen@freebsd.org>
Date
25 Oct 2007 19:17:42
Subject
Re: cvs commit: src/lib/libc/locale utf8.c
Message-ID
Pine.GSO.4.64.0710251516220.29092@sea.ntplx.net


[ Hide this part ]
On Thu, 25 Oct 2007, LI Xin wrote:

> Andrey Chernov wrote:
>> On Thu, Oct 25, 2007 at 09:44:06AM -0700, LI Xin 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.
>>> Do we really need to expose __mb_sb_limit outside libc?
>>
>> Yes, it is used in inlines compiled each time ctype.h included.
>
> Yes, I noticed that. So the problem would be, if a program has included
> ctype.h (_ctype.h) then it has the potential to require the symbol,
> which does not exist in previous releases.
>
> Having __inline functions sounds reasonable to me, though, because these
> functions are really small and may be called frequently. Maybe we can
> think out a way of avoiding the addition? It sounds like that
> potentially we will have trouble running binaries compiled on 6.3-R on
> 6.2-R systems, while this is acceptable IMO it is not very interesting
> for user community :-)

Why not simply avoid the error check for inlines. Solaris
doesn't seem to add a check, it just does the conversion.
The non-inlined versions do error checking.

--
DE


Elapsed time: 0.170 seconds