This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/2] new gconv modules for digital TV encodings
- From: Florian Weimer <fweimer at redhat dot com>
- To: tskd08 at gmail dot com, libc-help at sourceware dot org, carlos at systemhalted dot org
- Date: Tue, 17 Mar 2015 09:03:31 +0100
- Subject: Re: [PATCH 0/2] new gconv modules for digital TV encodings
- Authentication-results: sourceware.org; auth=none
- References: <20150305223255 dot GD19311 at vapier> <1425654747-6213-1-git-send-email-tskd08 at gmail dot com> <20150313060322 dot GK877 at vapier>
On 03/13/2015 07:03 AM, Mike Frysinger wrote:
> my limited understanding of gconv is that the API isn't formalized
> either for external users.
The API (and ABI) is extensively documented in the manual. glibc did
not actually implement it, but I think we are much closer to the
documentation since 2.21.
> since this area of glibc has settled down now, it might be nice to
> clean it up a bit and actually formalize it. that'd allow people
> such as yourself to build and distribute gconv modules
> independently so others could at least benefit. of course, we'd
> need someone to champion that work :).
The gconv code is a mess, we should not standardize on this. We do
not even have people willing to review cleanups there (I tried).
My main concern with gconv modules is that there are no unused ones.
If you use mutt or Evolution (and I'm sure there are other programs
similarly affected), a crafted mail message can trigger decoding with
any installed gconv module. This means that all gconv modules have to
be close to perfect. This is what makes affecting new gconv modules
difficult. New modules affect *many* users.
Florian Weimer / Red Hat Product Security