Problem: error in iconv_open
Mentore Siesto
I was asked recently to try and port AESCrypt
http://www.aescrypt.com/linux_aes_crypt.html
make went fine after modifying the makefile. After making the
executable file, though, testing it will always give me this:
[U:\progetti\aescrypt305_source\src]make -f makefile.os2 testfile
./aescrypt -e -p "praxis" test.orig.txt
Error in iconv_open: Invalid argument
make: *** [testfile] Error 255
Searching the password.c file (which contains iconv_open) I came
across these sentences:
/*
* passwd_to_utf16
*
* Convert String to UTF-16LE for windows compatibility
*/
int passwd_to_utf16(char *in_passwd,
int length,
int max_length,
char *out_passwd)
{
char *ic_outbuf,
*ic_inbuf;
iconv_t condesc;
size_t ic_inbytesleft,
ic_outbytesleft;
ic_inbuf = in_passwd;
ic_inbytesleft = length;
ic_outbytesleft = max_length;
ic_outbuf = out_passwd;
if ((condesc = iconv_open("UTF-16LE", nl_langinfo(CODESET))) ==
(iconv_t)(-1))
{
perror("Error in iconv_open");
return -1;
}
The remainder of the function calls iconv to convert the given
password and use it.
It seems that the error is caused by the nl_langinfo(CODESET) call,
which gives (on my system) "en_US"; this seems to cause the iconv_open
error.
Of course I tried substituting it with other ideas, like using getenv
to retrieve the locale, but still got errors.
I tried to learn how iconv and iconv_open work, but it seems rather
confusing to me.
Would someone of you be so kind to suggest me a way to circumvent this
problem? Having AES Crypt available would be useful.
Thanks in advance!
Mentore
--
Mentore Siesto
Dave Yeo
What iconv are you using? Not all iconv implementations are equal and
the one that is in klibc is slightly different then GNU libiconv. Some
configure scripts test for this and have different code for different
implementations.
When building for my personal use I often just do configure
--disable-iconv, if that isn't an option you could bypass the convert to
UTF16 function as it doesn't make much sense on OS/2 or install GNU
libiconv, there is a version here,
http://bauxite.sakura.ne.jp/software/os2/#libiconv that I've never tested.
Dave
KO Myung-Hun
If you use kLIBC, it does not support UTF-16LE encoding. Instead, use
UCS-2LE.
Or, if you really want to use UTF-16LE, you can use GNU libiconv as Dave
Yeo said.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.0.11
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
Mentore Siesto
<ko...@chollian.net> ha scritto:
I was hoping to get such answers :)
Ok, first of all I'm going to try a different encoding and then GNU
libiconv. Will keep you informed (next goal will be updating gnuplot!)
Thanks a lot, guys, you are invaluable as always.
Mentore
Mentore Siesto
<ko...@chollian.net> ha scritto:
> Hi/2.
>
> Mentore Siesto wrote:
> > Hello all, this is a rather strange problem.
> >
> > I was asked recently to try and port AESCrypt
>
> If you use kLIBC, it does not support UTF-16LE encoding. Instead, use
> UCS-2LE.
>
> Or, if you really want to use UTF-16LE, you can use GNU libiconv as Dave
> Yeo said.
Ok, just tried: using UCS-2LE worked fine, but now stops in trying to
open /dev/urandom. Since the OS/2 filesystems don't have the /dev
paradygm, I must find another way. Will search something good and
OS/2-aware!
Thanks again!
Mentore
Dave Yeo
> Ok, just tried: using UCS-2LE worked fine, but now stops in trying to
> open /dev/urandom. Since the OS/2 filesystems don't have the /dev
> paradygm, I must find another way. Will search something good and
> OS/2-aware!
>
> Thanks again!
There's an random number generator in OpenSSl and probably ssh, not sure
of the licencing
Dave
Ilya Zakharevich
> Ok, just tried: using UCS-2LE worked fine, but now stops in trying to
> open /dev/urandom. Since the OS/2 filesystems don't have the /dev
> paradygm, I must find another way.
It does have the /dev paradigm.
(echo foo >\dev\con) | tee aa
dir aa
I might have even seen a driver which implements urandom; check hobbes...
Ilya
Mentore Siesto
<nospam...@ilyaz.org> ha scritto:
For this specific version, the best solution is imho to use another
random number generator. I don't think my friend would be delighted to
need installing a device driver...
Anyway I'll check out hobbes, this could turn out to be good. Thanks
Ilya!
Mentore
piesse
> I might have even seen a driver which implements urandom; check hobbes...
maybe this thing?
http://r6.ca/RexxEGD/
piersante
Mentore
It's a REXX library, and the program I'm working on is in C. I would
like to make my modifications and see if the original creators can
take them into the official source.
Mentore
Mentore Siesto
<dave....@gmail.com> ha scritto:
I just resorted using the normal rand() function and it seems working.
If it does, I will consider using some other opensource random number
generator, now that I worked out modifiyng the source to make it OS/2
compatible (just added #ifdef OS2 into the source).
Mentore
--
Mentore Siesto
Dave Yeo
Probably good enough unless your communicating nuclear secrets are some
such. There's way more low hanging fruit then cracking the OS/2 random
number generator to predict it.
Dave
Ilya Zakharevich
> Probably good enough unless your communicating nuclear secrets are some
> such. There's way more low hanging fruit then cracking the OS/2 random
> number generator to predict it.
??? Did you have your coffee? There is no "OS/2 random
number generator"; it is CRTL's random number generator. There are
about 3 or 4 of them. There is no need to "crack them"; unless
seed()ed from urandom, they would return a fully predictable sequence
of numbers (provided the seeding happens from course-granularity
time, and PID).
Ilya
Mentore Siesto
<nospam...@ilyaz.org> ha scritto:
> On 2011-06-19, Dave Yeo <dave....@gmail.com> wrote:
News from past days...
I tried with rand () and it seemed to work fine, but now the program
seems to corrupt files!
Testing on a simple text file worked fine, but as I try it with a
binary file, my port corrupts it adding spare bytes.
It could be the way I'm using the random generator... I will make some
other try. Will keep you informed!
Mentore
Mentore Siesto
<mentor...@fattimiei.zx> ha scritto:
It was not the random number generator. I built another release using
another generator, which uses a specific algorithm, and noticed the
very same problem. So I checked out the fopen () calls, as the program
worked fine with text file, and guess what?
Yes, the original source opens files without the "binary" flag. adding
"b" to all the fopen () calls solved the problem.
Now it's just time to clean up a bit and a new OS/2 program is ready
:)
Mentore
Lars Erdmann
> It was not the random number generator. I built another release using
> another generator, which uses a specific algorithm, and noticed the
> very same problem. So I checked out the fopen () calls, as the program
> worked fine with text file, and guess what?
>
> Yes, the original source opens files without the "binary" flag. adding
> "b" to all the fopen () calls solved the problem.
Use of "fopen":
The usual pitfall when porting UNIX type programs to Windows or OS/2.
UNIX makes no distinction between text and binary files. Therefore it opens
all files as binary files (even though in the C-RTL you can specify binary
or text).
Windows and OS/2 on the other hand open files as text files as a default.
(unless the C-RTL specifies otherwise).
Lars
Dave Yeo
> It was not the random number generator. I built another release using
> another generator, which uses a specific algorithm, and noticed the
> very same problem. So I checked out the fopen () calls, as the program
> worked fine with text file, and guess what?
>
> Yes, the original source opens files without the "binary" flag. adding
> "b" to all the fopen () calls solved the problem.
I often just compile and link with the -Zbin-files flag to avoid these
problems.
Unluckily -Zbin-files is broken when it comes to pipes
Dave
Mentore Siesto
<lars.e...@arcor.de> ha scritto:
Well, this time the problem was that I was ought to find a suitable
random number generator and create arrays of 32 unsigned char. The
conversion between unsigned int and unsigned char made me think
probably I was making a mistake in typecasting, that's why I didn't
think about fopen.
After a while I asked myself why it worked on text files, and voila,
the solution came.
Mentore
vsvi...@gmail.com
I am working on the jpeg image file encryption and decryption, for this downloaded the
source code from link :http://www.aescrypt.com/linux_aes_crypt.html for linux .
I cross compiled this code package and for arm-none-linux-gnueabi-gcc compiler.
But i am getting run time error "Error in iconv_open: Invalid argument" .
How this error i can solve and which library supports the UTF-16 in LINUX (ubuntu-10.10) please help me.
Processor : DM3730.
Thanks,
Vidya