Researching crash in bug 637

[Andreas Mohr]

On Tue, May 21, 2002 at 09:57:10PM +0200, Mehmet YASAR wrote:
> Hi,
> 
> I've a small patch that allows me to get "Font Explorer Light" go
> further, both app are relying on a Windows bug.
> 
> For example take the following code (see the log) :
> 
> int main(int argc, char* argv[])
> {
> int i;
> char buffer[20];
> 
> buffer[0] = buffer[1] = buffer[2] = 77;
> i = GetLocaleInfoA(0x409, LOCALE_IFIRSTDAYOFWEEK, buffer, 1);
> 
> printf("%d:%d ret=%d\n", buffer[0], buffer[1], i);
> return 0;
> }
> 
> On Win2K we have <54:77 ret=0>
> On Wine I have   <0 :77 ret=1>
> 
> We see that MS returns 0 as failure but modifies buffer[0] !
> The following patch should fix this.
> 
> Mehmet
> 
> 
> 
> 

> --- /home/mehmet/CVS/wine/ole/ole2nls.c	Sun Apr 28 15:42:21 2002
> +++ ole2nls.c	Tue May 21 21:33:58 2002
> @@ -574,6 +574,12 @@
>      }
>      /* if len=0 return only the length, don't touch the buffer*/
>      if (len) {
> +	/* We behave like Windows when len == 1 */
> +	if (len == 1)
> +	{
> +            buf[0] = retString[0];
> +            return 0;
> +	}
>  	lstrcpynA(buf,retString,len);
>  	return strlen(buf) + 1;
>      }
Wrong, I'd guess (way too specific).

I'm almost 100% sure (well, maybe I'm the one who's wrong :)
that Windows copies as many bytes len as you give it up to the retString size.
And if len < strlen(retString), then it returns 0 *after* having filled
a part of the buffer.
Also, maybe there's a problem with terminating '\0' handling for some len
values.
I.e. I'm *sure* that it'd modify 2 bytes if you give it len 2, but still
return 0 as the buffer size is too small.

It'd be good if you rechecked exact buffer writing behaviour under Windows
regarding "not enough buffer space" due to small len,
and also the windows behaviour in the special case when len is not enough
to copy the trailing '\0' of retString into buffer.

-- 
Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604                http://mohr.de.tt