"Colin Fowler" wrote:
This patch fixes a wrongly named variable in the last patch and also a minor
typo in the comment.
Please also set tab size in your editor to 8, and fix spacing problems
after that.
--
Dmitry.
"Ilya Shpigor" wrote:
Subject: [TRY 2] user32/tests: Add tests for STM_SETIMAGE and
STM_SETICONmessage processing
Do these tests pass on Wine? If not you need to use todo_wine in
appropriate places, or post a fix as [1/2] and the tests as [2/2].
Also, please add a check that once first Send
Henri Verbeet wrote:
> 2009/9/22 Vitaliy Margolen :
>> It does dereference the pointer. Here is your simple test. Compile it and
>> run it. See what happens.
>>
>> #include
>>
>> typedef struct _s_test
>> {
>>void *pointer;
>> } s_test;
>>
>> int main()
>> {
>>s_test *s = NULL;
>>long
Dear friends,
I have been reading your postings to this mailing list and some of other
documents at the web site of the Wine Community. I have really enjoyed
reading about your collaborative creative activities and your perspectives
on the free/open source software.
My name is Tiebing Shi and I
Chris Robinson skrev:
> On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
>> It actually does not dereference anything.
>
> Does the C standard specify that taking the address of a struct member being
> dereferenced doesn't actually cause a dereference, instead just offsetting?
It
Luke Benstead skrev:
> If it IS the case that this doesn't cause a crash and is perfectly
> valid, can someone explain to me how/why this works? Or point me (no
> pun intended) to the bit in the C spec that explains it? Coz the way I
> read it, it has to dereference dmW, otherwise how would the com
On Tue, Sep 22, 2009 at 02:56:05AM -0400, Mike Kaplinskiy wrote:
> On Tue, Sep 22, 2009 at 1:09 AM, Vitaliy Margolen
> wrote:
> > Ben Klein wrote:
> >> The question remains, how exactly does
> >> FIELD_OFFSET work, and does it end up dereferencing ca[5]?
> > It does pointer arithmetic and does not
On Tue, Sep 22, 2009 at 10:48 AM, Luke Benstead wrote:
> 2009/9/22 Ben Klein :
>> 2009/9/23 Luke Benstead :
>>> If it IS the case that this doesn't cause a crash and is perfectly
>>> valid, can someone explain to me how/why this works? Or point me (no
>>> pun intended) to the bit in the C spec tha
2009/9/22 Henri Verbeet :
> "s->pointer" refers to the value of the pointer if "pointer" is a
> pointer, but to the address of the first array element if "pointer" is
> an array. I.e. "&s->pointer[0]" as Nicolas posted.
>
To clarify a bit more, if it's an array the actual array elements are
stored
2009/9/22 Luke Benstead :
> 2009/9/22 Ben Klein :
>> 2009/9/23 Luke Benstead :
>>> If it IS the case that this doesn't cause a crash and is perfectly
>>> valid, can someone explain to me how/why this works? Or point me (no
>>> pun intended) to the bit in the C spec that explains it? Coz the way I
>
On Tuesday 22 September 2009 7:53:08 am Ben Klein wrote:
> Worth trying my sample code on non-GCC compilers then:
With all optimizations off (if I had non-GCC compilers, I'd try them).
But still, I'm not really saying this is a problem (especially since the
FIELD_OFFSET macro does this, and is u
2009/9/22 Chris Robinson :
> On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
>> It actually does not dereference anything.
>
> Does the C standard specify that taking the address of a struct member being
> dereferenced doesn't actually cause a dereference, instead just offsetting?
>
2009/9/23 Luke Benstead :
> If it IS the case that this doesn't cause a crash and is perfectly
> valid, can someone explain to me how/why this works? Or point me (no
> pun intended) to the bit in the C spec that explains it? Coz the way I
> read it, it has to dereference dmW, otherwise how would th
2009/9/23 Chris Robinson :
> On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
>> It actually does not dereference anything.
>
> Does the C standard specify that taking the address of a struct member being
> dereferenced doesn't actually cause a dereference, instead just offsetting?
>
2009/9/22 Ben Klein :
> 2009/9/23 Luke Benstead :
>> If it IS the case that this doesn't cause a crash and is perfectly
>> valid, can someone explain to me how/why this works? Or point me (no
>> pun intended) to the bit in the C spec that explains it? Coz the way I
>> read it, it has to dereference
2009/9/22 Luke Benstead :
> 2009/9/22 Ben Klein :
>> 2009/9/22 Vitaliy Margolen :
>>> Mike Kaplinskiy wrote:
It actually does not dereference anything. Try passing null into the
function - it will work just fine. This is a special case because the
array isn't dynamically allocated bu
On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
> It actually does not dereference anything.
Does the C standard specify that taking the address of a struct member being
dereferenced doesn't actually cause a dereference, instead just offsetting?
Doing foo-> is identical to (*foo)
2009/9/22 Ben Klein :
> 2009/9/22 Vitaliy Margolen :
>> Mike Kaplinskiy wrote:
>>> It actually does not dereference anything. Try passing null into the
>>> function - it will work just fine. This is a special case because the
>>> array isn't dynamically allocated but is part of the struct, which
>>
2009/9/22 Vitaliy Margolen :
> Mike Kaplinskiy wrote:
>> It actually does not dereference anything. Try passing null into the
>> function - it will work just fine. This is a special case because the
>> array isn't dynamically allocated but is part of the struct, which
>> means that dmW->dmFormName
2009/9/22 Vitaliy Margolen :
> It does dereference the pointer. Here is your simple test. Compile it and
> run it. See what happens.
>
> #include
>
> typedef struct _s_test
> {
> void *pointer;
> } s_test;
>
> int main()
> {
> s_test *s = NULL;
> long diff = (const char*)s->pointer - (co
By default, it references icons in resource DLLs, but it can be configured
for regular ICO files.
On Tue, Sep 22, 2009 at 8:25 AM, Francois Gouget wrote:
> On Mon, 21 Sep 2009, King InuYasha wrote:
> [...]
> > Normally under Windows, it is possible to totally replace the icons for
> > almost eve
Mike Kaplinskiy wrote:
> It actually does not dereference anything. Try passing null into the
> function - it will work just fine. This is a special case because the
> array isn't dynamically allocated but is part of the struct, which
> means that dmW->dmFormName == (dmW+__offset of dmFormName) and
On Mon, 21 Sep 2009, King InuYasha wrote:
[...]
> Normally under Windows, it is possible to totally replace the icons for
> almost everything through the File types and associations dialog. You can
> even change the icon of a file folder. I don't think most people are aware
> that Windows can have
I've been looking into the ole32:clipboard test failures
(http://test.winehq.org/data/tests/ole32:clipboard.html) I'm now convinced that
Windows simply doesn't handle FORMATETC.ptd correctly when retrieving an
IDataObject via OleGetClipboard().
When looking at the test.winehq.org status page me
On Tuesday 22 September 2009 06:53:31 you wrote:
> > +SendMessageW(hStatic, STM_SETIMAGE, (WPARAM)IMAGE_ENHMETAFILE,
> > (LPARAM)hemf); +res = SendMessageW(hStatic, STM_SETIMAGE,
> > (WPARAM)IMAGE_ENHMETAFILE, (LPARAM)hemf); +ok(!res, "expected NULL
> > got 0x%lx\n", res);
>
> Is there
2009/9/21 Ralf Jung :
> I hope this does not sound offending, but why is Tango more of a standard
> than, e.g., Oxygen? I'm really just curious, please don't think I want to
> start a flame-war here. And, of course, I'd like to see wine integrated
> regardless of the desktop environment in use :
2009/9/22 Mike Kaplinskiy :
> On Tue, Sep 22, 2009 at 3:06 AM, Ben Klein wrote:
>> 2009/9/22 Mike Kaplinskiy :
>>> On Tue, Sep 22, 2009 at 1:09 AM, Vitaliy Margolen
>>> wrote:
> [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible
> null pointer dereference: dmW - otherw
Ralf Jung wrote:
> Hi,
>
>> It's true, not everyone is using Tango, but it's the closest thing we
>> have to a standard. It certainly wouldn't hurt to make Wine compatible
>> with multiple icon sets and then let packagers choose which one to use,
>> so I could provide a Gnome-wine and a KDE-wine
On Tue, Sep 22, 2009 at 3:06 AM, Ben Klein wrote:
> 2009/9/22 Mike Kaplinskiy :
>> On Tue, Sep 22, 2009 at 1:09 AM, Vitaliy Margolen
>> wrote:
[/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible
null pointer dereference: dmW - otherwise it is redundant to check if
>>>
2009/9/22 Mike Kaplinskiy :
> On Tue, Sep 22, 2009 at 1:09 AM, Vitaliy Margolen
> wrote:
>>> [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible
>>> null pointer dereference: dmW - otherwise it is redundant to check if
>>> dmW is null at line 272
>>
>> This is a real bug and sho
30 matches
Mail list logo
