Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
Eryk Wieliczko wrote:
> +if (!p_fopen_s)
> +{
> +win_skip("Skipping fopen_s test\n");
> +return;
> +}
> +else
> +{
> +/* testing fopen_s */
> +ret = p_fopen_s(&file, name, "w");
> +ok(ret == 0, "fopen_s failed with %d\n", ret);
> +ok(file != 0, "fopen_s failed to return value\n");
> +fwrite(name, sizeof(name), 1, file);
> +
> +ret = fclose(file);
> +ok(ret != EOF, "File failed to close\n");
> +
> +file = fopen(name, "r");
> +ok(file != 0, "fopen failed\n");
> +len = fread(buff, 1, sizeof(name), file);
> +ok(len == sizeof(name), "File length supposed to be %d, not %d\n",
> sizeof(name), len);
> +buff[sizeof(name)] = '\0';
> +ok(strcmp(name, buff) == 0, "File content mismatch! Got %s, expected
> %s\n", buff, name);
> +
> +ret = fclose(file);
> +ok(ret != EOF, "File failed to close\n");
> +
> +ok(_unlink(name) == 0, "Couldn't unlink file named '%s'\n", name);
> +}
> +}
The whole 'else { }' block is not necessary, same for the test below.
--
Dmitry.
Re: AUTHORS list and the C locale on Mac OS X
On 11/9/10 8:02 PM, Charles Davis wrote:
On 11/9/10 7:58 PM, James McKenzie wrote:
On 11/9/10 3:29 PM, Reece Dunn wrote:
On 9 November 2010 22:13, Charles Davis wrote:
On 11/9/10 1:58 PM, James Mckenzie wrote:
Charles Davis wrote:
On 11/9/10 12:13 PM, James Mckenzie wrote:
No, it is not a bug in GNU sed. The authors.c file needs to have
the erroneous characters for the language used by
MacOSX changed to be acceptable?
That ain't gonna fly. I think we should explicitly use a UTF-8 locale
(like en_US.UTF-8 or some such) instead of the C locale when sed goes
over the AUTHORS file.
Don't shoot the messenger.
Sorry.
The problem with your first idea--removing the bad characters directly
from the authors.c file--is that we'd need to use a utility like sed or
awk to implement it automatically--which puts us right back where we
started. (We could use diff/patch, but is it worth the effort to
maintain a patch for this? And would AJ let us put the patch file in
Wine? And if not, where would we put it?)
Maybe we can force the use of sed if it exists in the /usr/bin
directory then to get around the 'brokenness' of GNU sed on the Mac?
Maybe. But that seems like a hack. A better way might be to detect if
we're on Mac OS and using GNU sed; in that case, we use /usr/bin/sed.
That's less of a hack, but still a hack.
If not, it is a real bear to set the language on a Mac per
previous discussions on the Users list.
That was about setting LANG. Wine always obeys LC_*, and so does sed.
It's not the language that's the problem. It's the encoding. The AUTHORS
file is encoded in UTF-8, but GNU sed isn't using UTF-8 because we told
it not to (i.e. we told it to use MacRoman because that's the default
encoding for the C locale). If we tell it to use UTF-8 (by setting
LC_ALL to, for example, 'en_US.UTF-8'), it will process the file
correctly.
Unfortunately, I just remembered that the name of the UTF-8 encoding is
different on Mac OS ('UTF-8') and Linux ('utf8'). That might prevent us
from setting LC_ALL differently. We might end up having to hack around
this the way either you or I described.
You could use autoconf to detect:
1/ broken handling of UTF-8 characters by sed;
2/ name of LC_ALL flag that handles UTF-8
NOTE: You will need to enumerate available locales as the user may not
have en_US present with UTF-8 encoding (e.g. a Spanish-only or
Chinese-only system).
Something like:
cat> get_locale.sh< EOF
locale -a | while read locale ; do
if [[ LC_ALL=$locale sed< authors.c> /dev/null ]] ; then
echo $locale
exit
fi
done
EOF
This should print a locale that can process the UTF-8 file. It needs
cleaning up a bit, but that is the basis of it.
Thanks Reece.
Charles: You want to do this?
I'm on it.
If you have a patch ready, though, go for it.
No, I'm stuck with a problem in richedit. Besides you have more Mac
specific knowledge than I do, and I'm happy to say that. Although, if
you need a test 'victim' I'm here for you.
James McKenzie
Re: AUTHORS list and the C locale on Mac OS X
On 11/9/10 7:58 PM, James McKenzie wrote:
> On 11/9/10 3:29 PM, Reece Dunn wrote:
>> On 9 November 2010 22:13, Charles Davis wrote:
>>> On 11/9/10 1:58 PM, James Mckenzie wrote:
Charles Davis wrote:
> On 11/9/10 12:13 PM, James Mckenzie wrote:
>> No, it is not a bug in GNU sed. The authors.c file needs to have
>> the erroneous characters for the language used by
>> MacOSX changed to be acceptable?
> That ain't gonna fly. I think we should explicitly use a UTF-8 locale
> (like en_US.UTF-8 or some such) instead of the C locale when sed goes
> over the AUTHORS file.
Don't shoot the messenger.
>>> Sorry.
>>>
>>> The problem with your first idea--removing the bad characters directly
>>> from the authors.c file--is that we'd need to use a utility like sed or
>>> awk to implement it automatically--which puts us right back where we
>>> started. (We could use diff/patch, but is it worth the effort to
>>> maintain a patch for this? And would AJ let us put the patch file in
>>> Wine? And if not, where would we put it?)
Maybe we can force the use of sed if it exists in the /usr/bin
directory then to get around the 'brokenness' of GNU sed on the Mac?
>>> Maybe. But that seems like a hack. A better way might be to detect if
>>> we're on Mac OS and using GNU sed; in that case, we use /usr/bin/sed.
>>> That's less of a hack, but still a hack.
If not, it is a real bear to set the language on a Mac per
previous discussions on the Users list.
>>> That was about setting LANG. Wine always obeys LC_*, and so does sed.
>>>
>>> It's not the language that's the problem. It's the encoding. The AUTHORS
>>> file is encoded in UTF-8, but GNU sed isn't using UTF-8 because we told
>>> it not to (i.e. we told it to use MacRoman because that's the default
>>> encoding for the C locale). If we tell it to use UTF-8 (by setting
>>> LC_ALL to, for example, 'en_US.UTF-8'), it will process the file
>>> correctly.
>>>
>>> Unfortunately, I just remembered that the name of the UTF-8 encoding is
>>> different on Mac OS ('UTF-8') and Linux ('utf8'). That might prevent us
>>> from setting LC_ALL differently. We might end up having to hack around
>>> this the way either you or I described.
>> You could use autoconf to detect:
>>1/ broken handling of UTF-8 characters by sed;
>>2/ name of LC_ALL flag that handles UTF-8
>>
>> NOTE: You will need to enumerate available locales as the user may not
>> have en_US present with UTF-8 encoding (e.g. a Spanish-only or
>> Chinese-only system).
>>
>> Something like:
>>
>> cat> get_locale.sh< EOF
>> locale -a | while read locale ; do
>> if [[ LC_ALL=$locale sed< authors.c> /dev/null ]] ; then
>>echo $locale
>>exit
>> fi
>> done
>> EOF
>>
>> This should print a locale that can process the UTF-8 file. It needs
>> cleaning up a bit, but that is the basis of it.
>>
> Thanks Reece.
>
> Charles: You want to do this?
I'm on it.
If you have a patch ready, though, go for it.
Chip
Re: AUTHORS list and the C locale on Mac OS X
On 11/9/10 3:29 PM, Reece Dunn wrote:
On 9 November 2010 22:13, Charles Davis wrote:
On 11/9/10 1:58 PM, James Mckenzie wrote:
Charles Davis wrote:
On 11/9/10 12:13 PM, James Mckenzie wrote:
No, it is not a bug in GNU sed. The authors.c file needs to have the erroneous
characters for the language used by
MacOSX changed to be acceptable?
That ain't gonna fly. I think we should explicitly use a UTF-8 locale
(like en_US.UTF-8 or some such) instead of the C locale when sed goes
over the AUTHORS file.
Don't shoot the messenger.
Sorry.
The problem with your first idea--removing the bad characters directly
from the authors.c file--is that we'd need to use a utility like sed or
awk to implement it automatically--which puts us right back where we
started. (We could use diff/patch, but is it worth the effort to
maintain a patch for this? And would AJ let us put the patch file in
Wine? And if not, where would we put it?)
Maybe we can force the use of sed if it exists in the /usr/bin directory then
to get around the 'brokenness' of GNU sed on the Mac?
Maybe. But that seems like a hack. A better way might be to detect if
we're on Mac OS and using GNU sed; in that case, we use /usr/bin/sed.
That's less of a hack, but still a hack.
If not, it is a real bear to set the language on a Mac per previous
discussions on the Users list.
That was about setting LANG. Wine always obeys LC_*, and so does sed.
It's not the language that's the problem. It's the encoding. The AUTHORS
file is encoded in UTF-8, but GNU sed isn't using UTF-8 because we told
it not to (i.e. we told it to use MacRoman because that's the default
encoding for the C locale). If we tell it to use UTF-8 (by setting
LC_ALL to, for example, 'en_US.UTF-8'), it will process the file correctly.
Unfortunately, I just remembered that the name of the UTF-8 encoding is
different on Mac OS ('UTF-8') and Linux ('utf8'). That might prevent us
from setting LC_ALL differently. We might end up having to hack around
this the way either you or I described.
You could use autoconf to detect:
1/ broken handling of UTF-8 characters by sed;
2/ name of LC_ALL flag that handles UTF-8
NOTE: You will need to enumerate available locales as the user may not
have en_US present with UTF-8 encoding (e.g. a Spanish-only or
Chinese-only system).
Something like:
cat> get_locale.sh< EOF
locale -a | while read locale ; do
if [[ LC_ALL=$locale sed< authors.c> /dev/null ]] ; then
echo $locale
exit
fi
done
EOF
This should print a locale that can process the UTF-8 file. It needs
cleaning up a bit, but that is the basis of it.
Thanks Reece.
Charles: You want to do this?
James McKenzie
GetSystemPaletteEntries() patch
What was wrong with the patch sent in this post? http://article.gmane.org/gmane.comp.emulators.wine.devel/54403%29
Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
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=6922 Your paranoid android. === W98SE (32 bit file) === file.c:999: Test failed: smaller size block: Wrong error data () file.c:1007: Test failed: smaller size block: Stdout file shouldn't contain data
Re: krnl386.exe: Mention dosemu
On 11/9/10 4:20 PM, André Hentschel wrote: > @@ -643,7 +643,7 @@ static DWORD WINAPI MZ_DOSVM( LPVOID lpExtra ) > >if (GetLastError() == ERROR_NOT_SUPPORTED) >MESSAGE( "wine: Cannot start DOS application %s\n" > - " because vm86 mode is not supported on this > platform.\n", > + " because vm86 mode is not supported on this > platform, try dosemu.\n", You mean DOSBox, right? dosemu needs vm86(2) anyway, and AFAIK isn't even available on non-Linux. Chip
Re: AUTHORS list and the C locale on Mac OS X
On 9 November 2010 22:13, Charles Davis wrote:
> On 11/9/10 1:58 PM, James Mckenzie wrote:
>> Charles Davis wrote:
>>>
>>> On 11/9/10 12:13 PM, James Mckenzie wrote:
No, it is not a bug in GNU sed. The authors.c file needs to have the
erroneous characters for the language used by
MacOSX changed to be acceptable?
>>> That ain't gonna fly. I think we should explicitly use a UTF-8 locale
>>> (like en_US.UTF-8 or some such) instead of the C locale when sed goes
>>> over the AUTHORS file.
>>
>> Don't shoot the messenger.
> Sorry.
>
> The problem with your first idea--removing the bad characters directly
> from the authors.c file--is that we'd need to use a utility like sed or
> awk to implement it automatically--which puts us right back where we
> started. (We could use diff/patch, but is it worth the effort to
> maintain a patch for this? And would AJ let us put the patch file in
> Wine? And if not, where would we put it?)
>> Maybe we can force the use of sed if it exists in the /usr/bin directory
>> then to get around the 'brokenness' of GNU sed on the Mac?
> Maybe. But that seems like a hack. A better way might be to detect if
> we're on Mac OS and using GNU sed; in that case, we use /usr/bin/sed.
> That's less of a hack, but still a hack.
>> If not, it is a real bear to set the language on a Mac per previous
>> discussions on the Users list.
> That was about setting LANG. Wine always obeys LC_*, and so does sed.
>
> It's not the language that's the problem. It's the encoding. The AUTHORS
> file is encoded in UTF-8, but GNU sed isn't using UTF-8 because we told
> it not to (i.e. we told it to use MacRoman because that's the default
> encoding for the C locale). If we tell it to use UTF-8 (by setting
> LC_ALL to, for example, 'en_US.UTF-8'), it will process the file correctly.
>
> Unfortunately, I just remembered that the name of the UTF-8 encoding is
> different on Mac OS ('UTF-8') and Linux ('utf8'). That might prevent us
> from setting LC_ALL differently. We might end up having to hack around
> this the way either you or I described.
You could use autoconf to detect:
1/ broken handling of UTF-8 characters by sed;
2/ name of LC_ALL flag that handles UTF-8
NOTE: You will need to enumerate available locales as the user may not
have en_US present with UTF-8 encoding (e.g. a Spanish-only or
Chinese-only system).
Something like:
cat > get_locale.sh < EOF
locale -a | while read locale ; do
if [[ LC_ALL=$locale sed < authors.c > /dev/null ]] ; then
echo $locale
exit
fi
done
EOF
This should print a locale that can process the UTF-8 file. It needs
cleaning up a bit, but that is the basis of it.
HTH,
- Reece
Re: AUTHORS list and the C locale on Mac OS X
On 11/9/10 1:58 PM, James Mckenzie wrote:
> Charles Davis wrote:
>>
>> On 11/9/10 12:13 PM, James Mckenzie wrote:
>>> No, it is not a bug in GNU sed. The authors.c file needs to have the
>>> erroneous characters for the language used by
>>> MacOSX changed to be acceptable?
>> That ain't gonna fly. I think we should explicitly use a UTF-8 locale
>> (like en_US.UTF-8 or some such) instead of the C locale when sed goes
>> over the AUTHORS file.
>
> Don't shoot the messenger.
Sorry.
The problem with your first idea--removing the bad characters directly
from the authors.c file--is that we'd need to use a utility like sed or
awk to implement it automatically--which puts us right back where we
started. (We could use diff/patch, but is it worth the effort to
maintain a patch for this? And would AJ let us put the patch file in
Wine? And if not, where would we put it?)
> Maybe we can force the use of sed if it exists in the /usr/bin directory
> then to get around the 'brokenness' of GNU sed on the Mac?
Maybe. But that seems like a hack. A better way might be to detect if
we're on Mac OS and using GNU sed; in that case, we use /usr/bin/sed.
That's less of a hack, but still a hack.
> If not, it is a real bear to set the language on a Mac per previous
> discussions on the Users list.
That was about setting LANG. Wine always obeys LC_*, and so does sed.
It's not the language that's the problem. It's the encoding. The AUTHORS
file is encoded in UTF-8, but GNU sed isn't using UTF-8 because we told
it not to (i.e. we told it to use MacRoman because that's the default
encoding for the C locale). If we tell it to use UTF-8 (by setting
LC_ALL to, for example, 'en_US.UTF-8'), it will process the file correctly.
Unfortunately, I just remembered that the name of the UTF-8 encoding is
different on Mac OS ('UTF-8') and Linux ('utf8'). That might prevent us
from setting LC_ALL differently. We might end up having to hack around
this the way either you or I described.
Chip
Re: msvcrt: Fixed (_w)fopen_s always fails.
On Tue, Nov 9, 2010 at 9:38 PM, Eryk Wieliczko wrote:
> (_w)fopen_s were always failing due to regression introduced in
> commit 00f07046c0be658d97c47f69e1b4c518bc06b3a2
> ---
> dlls/msvcrt/file.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c
> index 329cdeb..91cd448 100644
> --- a/dlls/msvcrt/file.c
> +++ b/dlls/msvcrt/file.c
> @@ -2742,7 +2742,7 @@ int CDECL MSVCRT_fopen_s(MSVCRT_FILE** pFile,
> const char *filename, const char *mode)
> {
> if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename !=
> NULL) ||
> - MSVCRT_CHECK_PMT(mode != NULL)) {
> + !MSVCRT_CHECK_PMT(mode != NULL)) {
> *MSVCRT__errno() = MSVCRT_EINVAL;
> return MSVCRT_EINVAL;
> }
> @@ -2769,7 +2769,7 @@ int CDECL MSVCRT__wfopen_s(MSVCRT_FILE** pFile, const
> MSVCRT_wchar_t *filename,
> const MSVCRT_wchar_t *mode)
> {
> if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename !=
> NULL) ||
> - MSVCRT_CHECK_PMT(mode != NULL)) {
> + !MSVCRT_CHECK_PMT(mode != NULL)) {
> *MSVCRT__errno() = MSVCRT_EINVAL;
> return MSVCRT_EINVAL;
> }
> --
> 1.7.0.4
Sounds like a good reason to add a unit test to prevent it from
happening again, then.
--
-Austin
Re: AUTHORS list and the C locale on Mac OS X
Charles Davis wrote: > >On 11/9/10 12:13 PM, James Mckenzie wrote: >> No, it is not a bug in GNU sed. The authors.c file needs to have the >> erroneous characters for the language used by >> MacOSX changed to be acceptable? >That ain't gonna fly. I think we should explicitly use a UTF-8 locale >(like en_US.UTF-8 or some such) instead of the C locale when sed goes >over the AUTHORS file. Don't shoot the messenger. Maybe we can force the use of sed if it exists in the /usr/bin directory then to get around the 'brokenness' of GNU sed on the Mac? If not, it is a real bear to set the language on a Mac per previous discussions on the Users list. James McKenzie
Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
Am 09.11.2010 18:39, schrieb Henri Verbeet: 2010/11/9 Rico Schüller: I made the assumption, because setting the vtbl is the first thing d3dcompiler_shader_reflection_init() does. It is, but you're not supposed to care. Abstractions aren't very useful if you have to care about the details of their internals. Well, a heap free isn't always enough, because there could already be allocated data to the object, which then would resolve in lost memory. d3dcompiler_shader_reflection_init() should free anything it allocated if it's going to fail. Ok, it does that, if HeapAlloc and IUnknown_Release() is moved to d3dcompiler_shader_reflection_init(). So everything would be fine.
Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 6
What's wrong now? Chip
Re: AUTHORS list and the C locale on Mac OS X
On 11/9/10 12:13 PM, James Mckenzie wrote: > No, it is not a bug in GNU sed. The authors.c file needs to have the > erroneous characters for the language used by MacOSX changed to be acceptable? That ain't gonna fly. I think we should explicitly use a UTF-8 locale (like en_US.UTF-8 or some such) instead of the C locale when sed goes over the AUTHORS file.
Re: AUTHORS list and the C locale on Mac OS X
Charles Davis wrote: > >Hi, > >There may be a problem with the way the authors.c file is generated on a >Mac with GNU sed installed. > >On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. >This has some pretty surprising consequences. For example, since the >AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the >MacRoman encoding, GNU sed doesn't match those sequences in the .* >regexp, and the authors.c file comes out wrong. Mac OS sed does not have >this problem. So now I'm stuck changing the Makefile to use the system >sed (in /usr/bin) instead of GNU sed. > I found this a long time ago. Fink just modifies the Authors.c file to remove those sequences. I went one better and removed GNU sed from my Mac (fink purge sed) as I found that MacOSX version of sed would do everything that GNU sed did and I did not have to edit the file. >I could uninstall GNU sed, but there's one small problem. I have a >Gentoo prefix set up. It is the reason I have GNU sed installed. If I >install or upgrade practically anything in my Gentoo prefix, then GNU >sed will just get pulled right back in. > >Reading the manual for GNU sed tells me that this is by design and that >this behavior--not matching characters that are invalid in the current >locale--is in fact mandated by POSIX. If that's the case, then the >LC_ALL= statement in the Makefile needs to change. To what, I don't >know. I'm hoping one of you has an idea. > >If you think, however, that this is a bug in GNU sed, then I will gladly >write a report to the maintainer about it. > No, it is not a bug in GNU sed. The authors.c file needs to have the erroneous characters for the language used by MacOSX changed to be acceptable? James McKenzie
AUTHORS list and the C locale on Mac OS X
Hi, There may be a problem with the way the authors.c file is generated on a Mac with GNU sed installed. On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. This has some pretty surprising consequences. For example, since the AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the MacRoman encoding, GNU sed doesn't match those sequences in the .* regexp, and the authors.c file comes out wrong. Mac OS sed does not have this problem. So now I'm stuck changing the Makefile to use the system sed (in /usr/bin) instead of GNU sed. I could uninstall GNU sed, but there's one small problem. I have a Gentoo prefix set up. It is the reason I have GNU sed installed. If I install or upgrade practically anything in my Gentoo prefix, then GNU sed will just get pulled right back in. Reading the manual for GNU sed tells me that this is by design and that this behavior--not matching characters that are invalid in the current locale--is in fact mandated by POSIX. If that's the case, then the LC_ALL= statement in the Makefile needs to change. To what, I don't know. I'm hoping one of you has an idea. If you think, however, that this is a bug in GNU sed, then I will gladly write a report to the maintainer about it. Chip
Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
2010/11/9 Rico Schüller : > I made the assumption, because setting the vtbl is the first thing > d3dcompiler_shader_reflection_init() does. It is, but you're not supposed to care. Abstractions aren't very useful if you have to care about the details of their internals. > Well, a heap free isn't always enough, because there could already be > allocated data to the object, which then would resolve in lost memory. > d3dcompiler_shader_reflection_init() should free anything it allocated if it's going to fail.
Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
Am 09.11.2010 12:01, schrieb Henri Verbeet:
2010/11/8 Rico Schüller:
-object->vtbl =&d3dcompiler_shader_reflection_vtbl;
-object->refcount = 1;
+hr = d3dcompiler_shader_reflection_init(object, data, data_size, riid);
+if (FAILED(hr))
+{
+WARN("Failed to initialize shader reflection\n");
+IUnknown_Release((IUnknown *)object);
+return hr;
+}
You can't do that. Since d3dcompiler_shader_reflection_init() is
responsible for setting the vtbl, you can't assume it's set if
d3dcompiler_shader_reflection_init() fails. You'll have to use
HeapFree() here.
I made the assumption, because setting the vtbl is the first thing
d3dcompiler_shader_reflection_init() does.
Well, a heap free isn't always enough, because there could already be
allocated data to the object, which then would resolve in lost memory.
So my sugguestion is to move the HeapAlloc into
d3dcompiler_shader_reflection_init(ID3D11ShaderReflection **reflector,
const void *data, ...), from there it is safe to assume that the vtbl is
set before the release.
+if (!IsEqualGUID(riid,&IID_ID3D11ShaderReflection))
+{
+WARN("Wrong rrid %s, accept only %s!\n", debugstr_guid(riid),
debugstr_guid(&IID_ID3D11ShaderReflection));
+return E_FAIL;
+}
This can be done in D3DReflect() before even allocating the reflection
object. (Also, "rrid" is a typo.)
Yes, that can be done.
Cheers
Rico
Re: gdi32: Remove broken check for WinXP.
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=6910 Your paranoid android. === W2KPROSP4 (32 bit font) === Failure running script in VM: Exceeded timeout limit of 315 sec
Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
2010/11/8 Rico Schüller :
> -object->vtbl = &d3dcompiler_shader_reflection_vtbl;
> -object->refcount = 1;
> +hr = d3dcompiler_shader_reflection_init(object, data, data_size, riid);
> +if (FAILED(hr))
> +{
> +WARN("Failed to initialize shader reflection\n");
> +IUnknown_Release((IUnknown *)object);
> +return hr;
> +}
You can't do that. Since d3dcompiler_shader_reflection_init() is
responsible for setting the vtbl, you can't assume it's set if
d3dcompiler_shader_reflection_init() fails. You'll have to use
HeapFree() here.
> +if (!IsEqualGUID(riid, &IID_ID3D11ShaderReflection))
> +{
> +WARN("Wrong rrid %s, accept only %s!\n", debugstr_guid(riid),
> debugstr_guid(&IID_ID3D11ShaderReflection));
> +return E_FAIL;
> +}
This can be done in D3DReflect() before even allocating the reflection
object. (Also, "rrid" is a typo.)
Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
va_copy only exists in C99
wine requires C89 only
A+
2010/11/8 David Laight
>
> On Wed, Nov 03, 2010 at 10:53:55AM +0100, Alexandre Julliard wrote:
> > Eric Pouech writes:
> >
> > > +int CDECL _vcprintf(const char* format, __ms_va_list xvalist)
> > > {
> > >char buf[2048], *mem = buf;
> > >int written, resize = sizeof(buf), retval;
> > > - __ms_va_list valist;
> > > + __ms_va_list valist = xvalist;
> >
> > You can't copy a valist. This needs to be integrated properly with the
> > other printf functions.
>
> Well, you can if you can find a va_copy() function .
>
>David
>
> --
> David Laight: da...@l8s.co.uk
>
>
>
>
--
--
Eric Pouech
Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
to sum up the recent discrepencies between msvcrt and msvcrN0 Dlls: - msvcrt doesn't raise exception on _s functions while msvcrN0 does - (likely) in _s functions returning an errno_t value, msvcrt does set errno to the returned value, while msvcrN0 doesn't change the errno value (tested on _itoa_s and wcsncat_s) I wonder if should challenge the current scheme of forwarding all APIs from msvcrN0 to msvcrt (and writing wrappers in msvcr90 to cope with the various discrepencies) we could let msvcrt behave differently when loaded from our msvcrN0 DLLs than when loaded standalone, and factorize the discrepencies within msvcrt itself comments welcome A+ -- Eric Pouech
