On Wed, Nov 23, 2011 at 2:23 PM, JonY <jo...@users.sourceforge.net> 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
------------------------------------------------------------------------------
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
