On 11/23/2011 21:30, Vincent Torri wrote: > On Wed, Nov 23, 2011 at 2:23 PM, JonY <[email protected]> wrote: > >> On 11/23/2011 20:58, JonY wrote: >>> On 11/23/2011 20:44, Ruben Van Boxem wrote: >>>> I found winiconv some time ago, and noticed this little bit in the >> readme: >>>> >>>>> Win32 API does not support strict encoding conversion for some codepage >>>>> and MLang function drop or replace invalid bytes and does not return >>>>> useful error status as iconv. This implementation cannot be used for >>>>> encoding validation purpose. >>>> >>>> >>>> This means (to me) that winiconv is a simple wrapper around the >>>> conversions supported by the Win32 API, which is frightfully >>>> little.The failure to do anything more is probably the reason for >>>> winiconv's simplicity, but also cuts into its functionality. >>>> Integrating it into the crt would mean people come complaining when >>>> they discover the included iconv is missing crucial functionality, and >>>> they should have never switched from using a complete implementation >>>> like libiconv. >>>> >>> >>> The gcc weak-aliasing feature should allow them to continue using >>> libiconv, its still important that we don't break libiconv users. >>> >>> If users need more features, they simply recompile with libiconv. >>> >>>> If the limitations are removed and proven to work well, I'm all for >>>> it, but adding half-finished work seems to me a little >>>> counterproductive. It would also make it harder to use winiconv in a >>>> MSVC environment, where that might be easy now. This may be important >>>> if winiconv proves its worth. libiconv is a little harder to use under >>>> MSVC. >>> >>> As I was told, win-iconv must be able to work with MSVC, so we can have >>> all that __MINGW32__ && __GNUC__ ifdef stuff in a separate header to >>> keep things clean. >>> >>> Please CC everyone next time, thanks. >>> >> >> Redirecting to public list, use the public list instead of the >> restricted developer list. >> >> For readers just joining in, this thread is about integrating win-iconv >> into mingw-w64 in a non-intrusive way, it should allow libiconv users to >> continue with libiconv and overide win-iconv should it be integrated. >> >> win-iconv is minimalist when compared to libiconv, so it should not add >> much weight to executable size. >> > > I'm actually using win-iconv in the project i'm working on. You mean that > iconv will be part of the libc ? > > Vincent Torri
Yes, more specifically, in libmingwex so it will be transparent like on glibc. Of course, all its global visible symbols have to be marked as weak so to allow external win-iconv or libiconv to override it if users choose to.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
