Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2008-07

iconv unit/problem

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marco van de Voort

Hi,

because there are several bugreports asking for an iconv header translations, and one contained a patch from Whitewind which I tried to cleanup and get working.

I now have a bit of an odd problem with it that it seems to decode one char less than the input specifies.

I tried to remedy this by always decoding a char more, but this messes up the number of bytes written.

I wrapped everything up in a little test that decodes twice (one with N chars as it should be one with N+1 chars) and a script to reproduce and put it at

http://www.stack.nl/~marcov/lenc.zip

Probably it is something horribly simple, but I'm not seeing it :-)

Marco

Ref:
http://bugs.freepascal.org/view.php?id=11429
http://bugs.freepascal.org/view.php?id=11203

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 8 lines
Hi, because there are several bugreports asking for an iconv header translations, and one contained a patch from Whitewind which I tried to cleanup and get working. I now have a bit of an odd problem with it that it seems to decode one char less than the input specifies.

Shouldn't you make allowances for the terminating #0 ? And doesn't a text file have a unicode marker at the start ?

Michael.

Reply by email

Marco van de Voort
to Michael Van Canneyt
Show quoted text 10 lines
On Tue, 15 Jul 2008, Marco van de Voort wrote: > because there are several bugreports asking for an iconv header > translations, and one contained a patch from Whitewind which I tried to > cleanup and get working. > > I now have a bit of an odd problem with it that it seems to decode one char > less than the input specifies. Shouldn't you make allowances for the terminating #0 ?

It's the input, not the output. It does this even when you set the output buffer really high. The man page doesn't mention a #0, and the behaviour is the same on Linux and FreeBSD so I assume intentional.

And doesn't a text file have a unicode marker at the start ?

It goes wrong before I/O, and the input is not unicode but text in a codepage.

Reply by email