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
26 matches
Mail list logo
