re: msvcrt: strncpy doesn't compliant C standard (try 3)
Minor problem:
+static void test_strncpy(void)
+{
+size_t len = 10;
+char *ret;
+char dst[len + 1];
Hmm. That last line is a VLA, and might not compile in all C
compilers because it's not allowed in C89.
http://stackoverflow.com/questions/448844/variable-sized-arrays-in-c
Wine seems to want to build in c89 compilers:
http://www.winehq.org/pipermail/wine-cvs/2011-April/076721.html
Try using a #define with a more unique name for the length instead,
or better yet, replace len=10 with len=sizeof(dst)-1 or something.
Larger problem:
ret = strncpy(dst, not_null_less, len);
This is ill-defined. You're copying 10 bytes from a 5 byte buffer.
Don't do that.
Also, passing a not-null-terminated string in as a special test case
doesn't seem interesting... just pass in the longer null-terminated
string, and specify a shorter length. Fewer test strings needed,
easier to read code.
Please run 'make check', and test using http://testbot.winehq.org,
before submitting patches.
winetestbot question
Hello, i like to know why the WXPX64 VM of winetestbot does not have the 32 bit vc runtime 2008. The other 64 bit VMs have the runtime installed. Because of the missing runtime each patch for the unit tests of the dlls msvcr90 and msvcp90 is marked as "Failed" at http://source.winehq.org/patches -- Stefan
Re: msvcrt: strncpy doesn't compliant C standard (try 3)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26638 Your paranoid android. === W2KPROSP4 (32 bit string) === string.c:2585: Test failed: dst != 012345 === WXPPROSP2 (32 bit string) === string.c:2585: Test failed: dst != 012345 === WXPX64 (32 bit string) === string.c:2585: Test failed: dst != 012345 === W2K3R2SESP2 (32 bit string) === string.c:2585: Test failed: dst != 012345 === WVISTAX64 (32 bit string) === string.c:2585: Test failed: dst != 012345 === W2K8SE (32 bit string) === string.c:2585: Test failed: dst != 012345 === W7PROX64 (32 bit string) === string.c:2585: Test failed: dst != 012345 === TEST64_W7SP1 (32 bit string) === string.c:2585: Test failed: dst != 012345
Re: msvcp90/tests: Add dynamically loaded functions for ARM
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26637 Your paranoid android. === WXPX64 (32 bit misc) === No test summary line found === WXPX64 (32 bit ios) === No test summary line found
Re: Request to add wow64 keyword to bugzilla
On Wed, 7 Aug 2013 21:07:29 +0200 Frédéric Delanoy wrote: > > There's no win32 keyword ; only win16 and win64 > > There wouldn't be any use anyway since it would be the default > I know; Ken pointed that out. I think I misread win16. Clearly I should not post before having coffee. -- Rosanne DiMesio
Re: msvcp90/tests: Skip tests on missing functions
Am 07.08.2013 10:27, schrieb Piotr Caban:
> On 08/06/13 23:00, André Hentschel wrote:
>> @@ -749,6 +749,13 @@ static BOOL init(void)
>>
>> SET(p_basic_istream_char_read_uint64,
>>
>> "??5?$basic_istream@DU?$char_traits@D@std@@@std@@QAEAAV01@AA_K@Z");
>> +
>> +if (!p_basic_istream_char_read_uint64)
>> +{
>> +skip("_basic_istream_char_read_uint64 not found, skipping
>> tests\n");
>> +return FALSE;
>> +}
>
> Why are you skipping the tests instead of properly initializing functions
> pointers on ARM?
Oops, not sure, most likely it was too late and i was in the "skip-mode"
because of msvcr90...
I'll send a new one
Re: Request to add wow64 keyword to bugzilla
On Wed, Aug 7, 2013 at 4:30 PM, Ken Sharp wrote: > +1 from me. > > On 07/08/13 15:03, Rosanne DiMesio wrote: >> >> As to keyword usage, some of those bugs were tagged with the win64 >> keyword, some weren't. I know there is also a win32 keyword, and perhaps >> that is meant to be used for the kinds of bugs I am looking for, but if so, >> that is not at all clear from the keyword definition, and it is not how >> people are using the keywords. >> > > There's no win32 keyword? There's no win32 keyword ; only win16 and win64 There wouldn't be any use anyway since it would be the default Frédéric Delanoy
Re: Request to add wow64 keyword to bugzilla
+1 from me. On 07/08/13 15:03, Rosanne DiMesio wrote: On Wed, 07 Aug 2013 14:23:53 +0100 Ken Sharp wrote: Would I be right in assuming you would like to see bugs in 32-bit applications that are only present in a wow64 WINEPREFIX? Are there many? Yes. As to how many there are, I've been able to find 7 by doing searches of summaries/comments for things like "wow64" and "64" and then reading the bugs to see if they fit, but since people have such wildly varying ways of phrasing things, I don't know if that's all of them. I have seen it often enough on the forum that I now routinely tell 64 bit users to try a 32 bit wineprefix and have added instructions on how to create one to the FAQ. That's why I'd like an easier way to track these bugs. I see. A lot of people say this over and over again. +1 from me for a wow64 keyword. They may even be fairly easy to solve (picking the right paths / registry entries). As to keyword usage, some of those bugs were tagged with the win64 keyword, some weren't. I know there is also a win32 keyword, and perhaps that is meant to be used for the kinds of bugs I am looking for, but if so, that is not at all clear from the keyword definition, and it is not how people are using the keywords. There's no win32 keyword?
Re: Request to add wow64 keyword to bugzilla
On 07/08/13 13:59, Rosanne DiMesio wrote: Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit wineprefix. I'm interested in being able to track the latter, as it's hitting increasing numbers of users. The win64 keyword should only be used when 64-bit code is used and is the problem. It shouldn't be used just because the WINEPREFIX is 64-bit or that would be all Ubuntu users on AMD64 using the standard packages. Would I be right in assuming you would like to see bugs in 32-bit applications that are only present in a wow64 WINEPREFIX? Are there many?
Request to add wow64 keyword to bugzilla
Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit wineprefix. I'm interested in being able to track the latter, as it's hitting increasing numbers of users. -- Rosanne DiMesio
Re: msvcp90/tests: Skip tests on missing functions
On 08/06/13 23:00, André Hentschel wrote:
@@ -749,6 +749,13 @@ static BOOL init(void)
SET(p_basic_istream_char_read_uint64,
"??5?$basic_istream@DU?$char_traits@D@std@@@std@@QAEAAV01@AA_K@Z");
+
+if (!p_basic_istream_char_read_uint64)
+{
+skip("_basic_istream_char_read_uint64 not found, skipping
tests\n");
+return FALSE;
+}
Why are you skipping the tests instead of properly initializing
functions pointers on ARM?
Re: [PATCH] typo fixes (https://github.com/vlajos/misspell_fixer)
On Mon, Aug 5, 2013 at 9:41 PM, Veres Lajos wrote: > > Signed-off-by: Veres Lajos > --- > dlls/comctl32/tests/trackbar.c |2 +- > documentation/ChangeLog.ALPHA | 80 > > documentation/ChangeLog.BETA | 44 +++--- > documentation/ChangeLog.OLD| 24 ++-- > tools/winebuild/utils.c|2 +- > 5 files changed, 76 insertions(+), 76 deletions(-) The "documentation/ChangeLog.*" files have been removed so the patch won't apply. Frédéric Delanoy
Re: msvcrt: strncpy doesn't compliant C standard (try 2)
On Tue, Aug 6, 2013 at 10:44 PM, Álvaro Nieto wrote: > Remove strlen and implement some tests You should probably add tests for when the source string is not null-terminated. Frédéric Delanoy
