bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnu-libiconv] iconv_open() non-alnum chars


From: Bruno Haible
Subject: Re: [bug-gnu-libiconv] iconv_open() non-alnum chars
Date: Mon, 02 Jul 2018 12:43:25 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-128-generic; KDE/5.18.0; x86_64; ; )

[CCing bug-gnu-libiconv. Always send support questions to the mailing list,
 not through private email.]

Robert Nagy wrote:
> Hi!
> 
> I have been trying to debug an issue with a project when I ran into
> the issue that iconv_open() behaves differently in glibc and libiconv.
> 
> The issue is that glibc will accept any input to iconv_open() and will
> normalize that by removing all non alpha-numeric chars, but libiconv
> will just return EINVAL. 
> 
> The code below works fine with glibc but fails with libiconv. Now I
> do not know what would be the best to do but maybe it would be good to
> mimic what glibc does as I am sure there is a lot of software out there
> assuming that this will work and poor error checking will just make
> things worse on their end.
> 
> What is your opinion?
> 
> Thanks
> 
> #include <string.h>
> #include <errno.h>
> #include <err.h>
> #include <iconv.h>
> 
> int 
> main(int argc, char *argv[])
> {
>         iconv_t m_cd = iconv_open("CP1250", "\"UTF-8\"");
>         if (m_cd == (iconv_t)(-1))
>                 err(1, "%s", strerror(errno));
> 
>         return 0;
> }
> 

Hi,

> The code below works fine with glibc but fails with libiconv.

Interesting. I wasn't aware of this difference in behaviour.

What is the purpose of removing all non-alphanumeric characters
from a given codeset argument? I don't see a use-case for it. The glibc
implementation has a comment
  /* Normalize the name.  We remove all characters beside alpha-numeric,
     '_', '-', '/', '.', and ':'.  */
but it does not explain why.

Therefore I see no point to change libiconv here.

> I am sure there is a lot of software out there
> assuming that this will work

I don't think so. It's very unusual to pass garbage strings (i.e. strings
that don't conform to specifications) to iconv_open().

I prefer strict input checking to loose input checking, because loose input
checking can often turn into "garbage in - garbage out" program behaviour.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]