Fri 11 Feb 2011 10:11:54 AM UTC, comment #4:
For me too the iconv_string produces "Success" (iconv_string returns 0), but the returned pcResult is WRONG...
I've modified the sample to add a test when iconv_string returns 0. Can you check that you have the "Read Success" return ? In my case I have the "Success but bad result".
#include <string.h>
#include <stdio.h>
#include <locale.h>
#include "iconv_string.h"
int main(int argc, char** argv)
{
setlocale(LC_NUMERIC, "C");
char pcString[6] = {0x74,0x65,0x73,0x74,0xe9,0x00}; // In memory at &pcString in hexa there is: 74 65 73 74 e9 00 <- “testé”
size_t uiLength = strlen(pcString); // uiLength = 5
char* pcResult = 0;
int iRetVal = iconv_string("UTF-8", "autodetect_utf8", pcString, pcString+uiLength+1, &pcResult, &uiLength);
if (iRetVal < 0)
{
// pcResult should be : {0x74,0x65,0x73,0x74,0xc3,0xa9,0x00}
// and it is : {0xfd, 0xfd, 0xfd, 0xfd, 0xab, 0xab, 0xab, 0xab, 0xab, 0xab, 0xab, 0xab, 0xee, 0xfe, 0xee, 0xfe, 0x00}
perror("Failure");
}
else
{
if (pcResult[0] == 0x74)
{
perror("Real Success");
}
else
{
perror("Success but bad result");
return -1;
}
}
return iRetVal;
}
|
Thu 10 Feb 2011 11:07:40 AM UTC, comment #3:
Thank you for the requested sample program.
For me, on a glibc system with libiconv 1.13.1, it compiles
fine and produces "Success":
$ gcc -m32 -Wall foo.c \
-I libiconv/extras \
libiconv/extras/iconv_string.c \
-I /arch/x86-linux/gnu-inst-libiconv/1.13/include \
/arch/x86-linux/gnu-inst-libiconv/1.13/lib/libiconv.so -Wl,-rpath,/arch/x86-linux/gnu-inst-libiconv/1.13/lib
libiconv/extras/iconv_string.c: In function ‘iconv_string’:
libiconv/extras/iconv_string.c:77: warning: passing argument 2 of ‘libiconv’ from incompatible pointer type
libiconv/extras/iconv_string.c:129: warning: passing argument 2 of ‘libiconv’ from incompatible pointer type
These warnings are OK, it's the classical problem with
'const char *' vs. 'char *'.
$ ./a.out
Success: Invalid argument
The 'Invalid argument' means nothing, because the value of
'errno' is undefined when a function succeeds.
I conclude that the problem must be on your side:
- Either you're not using libiconv, but some other iconv
implementation.
- Or you're passing -I and -L parameters that mix up two
different iconv implementations.
- Or (if you're on Windows) you mixed libraries that use
different runtime libraries. Cf.
<http://www.gnu.org/software/gettext/FAQ.html#windows_howto>
|
Wed 09 Feb 2011 04:18:06 PM UTC, comment #1:
I cannot do anything with your code snippet, because
1) It is just a snippet, not a complete program.
2) In the initialization of pcString, you use non-ASCII characters
outside of comments. This is not portable (it depends on
the compiler and its notions of "source character set" and
"execution character set").
3) You are ignoring the return value of iconv_string.
Can you attach a test case that fixes all this? A complete
program, that use octal or hexadecimal escapes for non-ASCII
characters, and does proper processing of iconv_string's return
value?
|
Wed 09 Feb 2011 02:50:11 PM UTC, original submission:
Hello
There is a bug in iconv_string function (version 1.13.1)
The following code reproduces the bug:
{
char pcString[] = {'t','e','s','t','é','\0'};
// In memory at &pcString in hexa there is: 74 65 73 74 e9 00 <- “testé”
size_t uiLength = strlen(pcString); // uiLength = 5
char* pcResult = 0;
iconv_string("UTF-8", "autodetect_utf8", pcString, pcString+uiLength+1, &pcResult, &uiLength);
}
Returned pcResult is wrong : "ýýýý««««««««îþîþ" (in memory: fd fd fd fd ab ab ab ab ab ab ab ab ee fe ee fe 00)
If pcString is “tésté” the result is OK : "tésté" (in memory: 74 c3 a9 73 74 c3 a9 00)
It seems that the bug occurs when the ‘é’ character is in alone in the string and in last position.
Bye
|