Re: utffile patch

From: Max Khon <fjoe(at)samodelkin(dot)net>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Hiroshi Saito <saito(at)inetrt(dot)skcapi(dot)co(dot)jp>, pgadmin-hackers(at)postgresql(dot)org, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Subject: Re: utffile patch
Date: 2005-02-24 07:57:34
Message-ID: 20050224075734.GA37789@samodelkin.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi!

On Wed, Feb 23, 2005 at 10:26:05PM +0000, Andreas Pflug wrote:

> >Attached patch fixes coredump in non-Unicode version of pgadmin3.
> >This allows to build (non-Unicode) pgadmin3 on FreeBSD 4.x.
>
> This patch appears highly dubious to me (apart from the fact that I'd
> call non-unicode unsupported).
>
> >+#if wxUSE_UNICODE
> >+ size_t buf_len = nLen;
> >+#else
> >+ size_t buf_len = nLen * sizeof(wchar_t);
> >+#endif
> > +
> m_conversion->MB2WC((wchar_t*)(wxChar*)wxStringBuffer(str, buf_len),
> (const char*)buffer, (size_t)(nLen+1));
>
> wxStringBuffers expects the second parameter to contain the number of
> characters (not bytes), which will be the same for unicode as and
> non-unicode.

No. wxStringBuffer uses wxWCharBuffer in Unicode case and
wxCharBuffer in non-Unicode case.

> Using sizeof(wchar_t) in non-unicode is just an arbitrary
> number with no special meaning, might be the magic constant 42 as well.
> The only mechanism of "fix" I could think of is that wxStringBuffer
> really should receive nLen+1 instead of nLen.
>
> Max, apparently you have a test case, please check nLen+1 instead of
> buf_len.

It doesn't help.

/fjoe

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message cvs 2005-02-24 10:19:04 CVS Commit by andreas: require unicode to compile utffile.cpp
Previous Message blacknoz 2005-02-23 23:31:32 Re: upgrade to wx2.5.4