On 18 Jan 2006, at 15:30, Wim Oudshoorn wrote:
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
On 18 Jan 2006, at 11:16, Wim Oudshoorn wrote:
No, I mean 1. But that is just to try to make the problem simple
to grasp.
In practice, take the following example:
BUFSIZ = 1024
extra = 0
bsize = 1024 (it will be this value before the first GROW call)
dpos = 1023
sl = 1
dest = 0
However, it looks like that is an impossible example, since the code
says
if (dst == 0 || *size == 0)
{
ptr = buf;
bsize = (extra != 0) ? BUFSIZ - 1 : BUFSIZ;
}
Yes, that is the case when setting up. That is why bsize in the
first
run is equal to BUFSIZ. This is NOT the code in the GROW macro,
which will will do: ptr -= BUFSIZ.
Am I missing something here?
I think so. I am quite convinced I am right. But even when I am
convinced I have been proven wrong before ;-(
Do you have any code to demonstrate the problem actually happening?
Hm our application? But than, of course that is not a simple test
program.
At the moment I am really struggling with a very nasty memory
corruption problem
in a multithreaded environment. Grrr. So I won't have time to write
a small test application. But even a small test application does
not prove
anything. I could well be that it corrupts an innocent part of
thes stack.
OK ... I managed to write a test to reproduce it, and confirm that
the change I made fixed it.
I imagine this was an extremely rare problem since, I can't find much
to trigger it in the base library.
Unless I missed something, the only method which uses GSFromUnicode
with a null destination pointer seems to be cStringLength (we should
probably get a few other methods to use it for efficiency).
The bug would only be triggered for a string at least BUFSIZ bytes long.
The bug would only be triggered if the C string encoding is utf-8
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
