Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgadmin-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group