On Di, 2009-09-22 at 07:46 -0700, Chris Robinson wrote:
> so dmW->dmFormName is the same as &(*dmW).dmFormName,
When the target is an array, the address of the first member is
returned:
dmW->fmFormName is: &(dmW->dmFormName[0])
similar:
char buffer[32];
printf("buffer at %p\n", buffer);
which
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
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
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
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
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
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 dereference anything. "ca[5]" is the
> same as "(ca + 5)" or on lower level
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 dereference anything. "ca[5]" is the
same as "(ca + 5)" or on lower level "((char*)ca + 5*sizeof(ca[0]))" and
does not require any dereferen
2009/9/21 chris ahrendt :
> False positive ticket created for:
>
> [/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
>
> what about the others? or the suggestion of adding an addit
False positive ticket created for:
[/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
what about the others? or the suggestion of adding an additional int to
the array?
chris
2009/9/21 James Mckenzie :
>
>
> -Original Message-
>>From: Henri Verbeet
>>Sent: Sep 20, 2009 12:19 PM
>>To: Pauli Nieminen
>>Cc: wine-devel@winehq.org, Joris Huizer
>>Subject: Re: cppcheck Sept 18
>>
>>Not quite. For one, the ca[5] t
-Original Message-
>From: Henri Verbeet
>Sent: Sep 20, 2009 12:19 PM
>To: Pauli Nieminen
>Cc: wine-devel@winehq.org, Joris Huizer
>Subject: Re: cppcheck Sept 18
>
>2009/9/20 Pauli Nieminen
>>
>> On Sat, Sep 19, 2009 at 1:59 PM, Joris Huizer wrote:
2009/9/20 Pauli Nieminen
>
> On Sat, Sep 19, 2009 at 1:59 PM, Joris Huizer wrote:
>>
>> [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible
>> error) Array index out of bounds
>>
>> This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]),
>> and it found an array:
>> int
>[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible
>error) Array index out of bounds
>
>This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]),
>and it found an array:
>int ca[5];
>
Actually, if this is a zero offset array, this is out of bounds. It might be
better t
On Sat, Sep 19, 2009 at 1:59 PM, Joris Huizer wrote:
> [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible
> error) Array index out of bounds
>
> This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]),
> and it found an array:
> int ca[5];
>
> int ca[5];
has only entries
2009/9/19 Joris Huizer
> [/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
>
> That is a bug, sent a patch
>
> HTH,
>
> Joris
>
Joris,
As explained in a previous mail, there's no
[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd
[/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource
leak: fd_cwd
These two are false positives, as the process ends (calling exit(1)
[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible
[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd
[/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource
leak: fd_cwd
[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible
error) Array index out of bounds
[/home/cahrendt/wine-git/dlls/wineps.
34 matches
Mail list logo
