Bug#406946: iconv() crashes during ASCII -> WCHAR_T conversion on sparc

[Aurelien Jarno <aurelien@aurel32.net>]

reassign 406946 manpages-dev
thanks

Jurij Smakov a écrit :
> On Sat, Feb 03, 2007 at 06:01:16PM +0100, Aurelien Jarno wrote:
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <iconv.h>
>>> #include <string.h>
>>>
>>> int main()
>>> {
>>>         iconv_t cd;
>>>         size_t inr = 4, outr = 8, res;
>>>         char *inbuf = strdup("abcde");
>>>         char *outbuf = malloc(8);
>>>
>>>         inbuf++;

Note that doing such a thing you are in the middle of a character (a
character is 4-byte in the WCHAR_T format).

>>>         cd = iconv_open("ASCII", "WCHAR_T");
>>>         res = iconv(cd, &inbuf, &inr, &outbuf, &outr);
>>>
>>>         return 0;
>>> }
>> wchar_t type has a 32-bit size. It is perfectly normal to require a
>> 32-bit alignement on 32-bit types, just like it is already the case on
>> float and double.
>>
>> This testcase is buggy, not the iconv code.
> 
> I disagree. iconv(3) man page states, that the input and output buffer 
> are specified as char **inbuf and char **outbuf, implying that there 

The input and output buffer are defined as char** because this is the
common denominator of all supported types.

Quoting POSIX:
"The type of inbuf and outbuf, char **, does not imply that the objects
pointed to are interpreted as null-terminated C strings or arrays of
characters."

and later:
"The type of the data (char, short, long, and so on) read or stored in
the objects is not specified, but may be inferred for both the input and
output data by the converters determined by the fromcode and tocode
arguments of iconv_open ( )".

> are no specific alignment requirements for them. I also could not find 
> any mention of possible alignment issues in the documentation. Thus, I 
> think it is reasonable to expect that a valid iconv() implementation 
> will not to do any assumptions about the alignment of data buffers 
> which are passed to it.

The manpage is not provided by the glibc and thus is not a reference of
the glibc API.

The glibc documentation says:
"This looks rather innocent but can lead to problems on platforms that
have tight restriction on alignment.  Therefore the caller of `iconv'
has to make sure that the pointers passed are suitable for access of
characters from the appropriate character set."

I am therefore reassigning the bug to manpages-dev package.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net