Zeroing out the object struct

Dec 14, 2006 at 1:28am

Zeroing out the object struct

Hi there,

I have seen this done in some code:

void *myobj_new(t_symbol *s, short ac, t_atom *av)
{
t_myobj *x = (t_myobj *)object_alloc(myobj_class);
if (x) {
for (i = sizeof(t_pxobject); i <
sizeof(t_myobj); i++) {
((char *)x)[i] = 0;
}
}
// …rest of the code
}

Why? Is it necessary to zero out the object struct in
the new method of every external? I have seen
externals that don’t zero the struct and they work
flawlessly. Are there any potential risks in not doing
it?

Thanks for any advice.

- Luigi

————————————————————
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
————————————————————

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.

http://new.mail.yahoo.com

#29219
Dec 14, 2006 at 8:18am

No, this is an extremely bad idea. Don’t do that. Among other things,
object_alloc initializes that object struct, so that Max will
properly identify it as a valid Max object, and so that its list of
methods can be read.

Where do you get these weird ideas? Not a single object in the SDK
does this.

jb

Am 14.12.2006 um 02:28 schrieb Luigi Castelli:

> Why? Is it necessary to zero out the object struct in
> the new method of every external? I have seen
> externals that don’t zero the struct and they work
> flawlessly. Are there any potential risks in not doing
> it?

#90727
Dec 14, 2006 at 11:00am

It is true, in the Max/MSP SDK it is never done.
However, most objects in the PerColate collection -
for instance – zero their struct in the new method.
That’s why I thought about it…

- Luigi

— Jeremy Bernstein wrote:

> No, this is an extremely bad idea. Don’t do that.
> Among other things,
> object_alloc initializes that object struct, so that
> Max will
> properly identify it as a valid Max object, and so
> that its list of
> methods can be read.
>
> Where do you get these weird ideas? Not a single
> object in the SDK
> does this.
>
> jb
>
> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:
>
> > Why? Is it necessary to zero out the object struct
> in
> > the new method of every external? I have seen
> > externals that don’t zero the struct and they work
> > flawlessly. Are there any potential risks in not
> doing
> > it?
>
>

————————————————————
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
————————————————————

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.

http://new.mail.yahoo.com

#90728
Dec 14, 2006 at 1:37pm

Sorry, I misread the code. Sorry for flipping out.

OK, you are not zeroing out the t_pxobject, as I thought when I first
saw it, but the rest of the object, before assigning values to it.
This can’t do any harm, but it shouldn’t really be necessary,
assuming that you assign values to all of your struct members.

jb

Am 14.12.2006 um 12:00 schrieb Luigi Castelli:

> It is true, in the Max/MSP SDK it is never done.
> However, most objects in the PerColate collection -
> for instance – zero their struct in the new method.
> That’s why I thought about it…
>
> – Luigi
>
>
>
>
>
> — Jeremy Bernstein wrote:
>
>> No, this is an extremely bad idea. Don’t do that.
>> Among other things,
>> object_alloc initializes that object struct, so that
>> Max will
>> properly identify it as a valid Max object, and so
>> that its list of
>> methods can be read.
>>
>> Where do you get these weird ideas? Not a single
>> object in the SDK
>> does this.
>>
>> jb
>>
>> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:
>>
>>> Why? Is it necessary to zero out the object struct
>> in
>>> the new method of every external? I have seen
>>> externals that don’t zero the struct and they work
>>> flawlessly. Are there any potential risks in not
>> doing
>>> it?
>>
>>
>
>
>
> ————————————————————
> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT
> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY
> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS
> PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE
> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF
> THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
> ————————————————————
>
>
>
>
> ______________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com

#90729
Dec 14, 2006 at 7:57pm

This kind of precaution can definitely catch tricky bugs, maybe if
you use a macro like:

#define initialize_object(obj) (bzero( (void*)(obj + sizeof
(t_pbxobject)), sizeof(*obj) – sizeof(t_pbxobject) )

and then if you like condition that define on DEBUG or some other
preprocessor define.

Then you just write:

void *myobj_new(t_symbol *s, short ac, t_atom *av) {
t_myobj* x = (t_myobj *)object_alloc(myobj_class);
initialize_object(x);

}

_Mark

On Dec 14, 2006, at 5:37 AM, Jeremy Bernstein wrote:

> Sorry, I misread the code. Sorry for flipping out.
>
> OK, you are not zeroing out the t_pxobject, as I thought when I
> first saw it, but the rest of the object, before assigning values
> to it. This can’t do any harm, but it shouldn’t really be
> necessary, assuming that you assign values to all of your struct
> members.
>
> jb
>
> Am 14.12.2006 um 12:00 schrieb Luigi Castelli:
>
>> It is true, in the Max/MSP SDK it is never done.
>> However, most objects in the PerColate collection -
>> for instance – zero their struct in the new method.
>> That’s why I thought about it…
>>
>> – Luigi
>>
>>
>>
>>
>>
>> — Jeremy Bernstein wrote:
>>
>>> No, this is an extremely bad idea. Don’t do that.
>>> Among other things,
>>> object_alloc initializes that object struct, so that
>>> Max will
>>> properly identify it as a valid Max object, and so
>>> that its list of
>>> methods can be read.
>>>
>>> Where do you get these weird ideas? Not a single
>>> object in the SDK
>>> does this.
>>>
>>> jb
>>>
>>> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:
>>>
>>>> Why? Is it necessary to zero out the object struct
>>> in
>>>> the new method of every external? I have seen
>>>> externals that don’t zero the struct and they work
>>>> flawlessly. Are there any potential risks in not
>>> doing
>>>> it?
>>>
>>>
>>
>>
>>
>> ————————————————————
>> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT
>> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY
>> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS
>> PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE
>> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF
>> THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
>> ————————————————————
>>
>>
>>
>>
>> _______________
>> Do you Yahoo!?
>> Everyone is raving about the all-new Yahoo! Mail beta.
>> http://new.mail.yahoo.com
>

#90730
Dec 14, 2006 at 8:06pm

> #define initialize_object(obj) (bzero( (void*)(obj + sizeof
> (t_pbxobject)), sizeof(*obj) – sizeof(t_pbxobject) )

Sorry, that should have been:

#define initialize_object(obj) (bzero( (void*)(((char*)obj) + sizeof
(t_pbxobject)), sizeof(*obj) – sizeof(t_pbxobject) )

stupid pointer arithmatic..

_Mark

#90731
Dec 14, 2006 at 8:57pm

Actually, I was spending sometime today in GDB and it looks like
newobject() zeroes on it’s own, which is sort of useful.

I don’t think this is documented and I don’t know if anyone from
Cycling ’74 would want to comment (or guarantee the behavior)?

There are some things even better than zero, though, for catching
allocation bugs &c. If you look up DEADBEEF on Wikipedia, there’s a
whole article with lists of good crash-while-it’s-still-in-the-lab
constants.

– P.

On 14-Dec-2006, at 20:57, Mark Pauley wrote:

> This kind of precaution can definitely catch tricky bugs, maybe if
> you use a macro like:
>
> #define initialize_object(obj) (bzero( (void*)(obj + sizeof
> (t_pbxobject)), sizeof(*obj) – sizeof(t_pbxobject) )
>
> and then if you like condition that define on DEBUG or some other
> preprocessor define.
>
> Then you just write:
>
> void *myobj_new(t_symbol *s, short ac, t_atom *av) {
> t_myobj* x = (t_myobj *)object_alloc(myobj_class);
> initialize_object(x);
> …
> }
>
>
> _Mark
>
> On Dec 14, 2006, at 5:37 AM, Jeremy Bernstein wrote:
>
>> Sorry, I misread the code. Sorry for flipping out.
>>
>> OK, you are not zeroing out the t_pxobject, as I thought when I
>> first saw it, but the rest of the object, before assigning values
>> to it. This can’t do any harm, but it shouldn’t really be
>> necessary, assuming that you assign values to all of your struct
>> members.
>>
>> jb
>>
>> Am 14.12.2006 um 12:00 schrieb Luigi Castelli:
>>
>>> It is true, in the Max/MSP SDK it is never done.
>>> However, most objects in the PerColate collection -
>>> for instance – zero their struct in the new method.
>>> That’s why I thought about it…
>>>
>>> – Luigi
>>>
>>>
>>>
>>>
>>>
>>> — Jeremy Bernstein wrote:
>>>
>>>> No, this is an extremely bad idea. Don’t do that.
>>>> Among other things,
>>>> object_alloc initializes that object struct, so that
>>>> Max will
>>>> properly identify it as a valid Max object, and so
>>>> that its list of
>>>> methods can be read.
>>>>
>>>> Where do you get these weird ideas? Not a single
>>>> object in the SDK
>>>> does this.
>>>>
>>>> jb
>>>>
>>>> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:
>>>>
>>>>> Why? Is it necessary to zero out the object struct
>>>> in
>>>>> the new method of every external? I have seen
>>>>> externals that don’t zero the struct and they work
>>>>> flawlessly. Are there any potential risks in not
>>>> doing
>>>>> it?
>>>>
>>>>
>>>
>>>
>>>
>>> ————————————————————
>>> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT
>>> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY
>>> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS
>>> PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE
>>> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES
>>> OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
>>> ————————————————————
>>>
>>>
>>>
>>>
>>> ________________
>>> Do you Yahoo!?
>>> Everyone is raving about the all-new Yahoo! Mail beta.
>>> http://new.mail.yahoo.com
>>
>

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

#90732
Dec 20, 2006 at 1:53pm

I’ve always zeroed member-by-member, but that does have some
maintenance overhead when developing an object. The Percolate
approach has the advantage(?) that you don’t have to think.

However, I’ve been spending a pleasant afternoon with GDB (ahem) and
noticed newobject() appears to zero the entire object structure
automatically, at least on Intel-based Mac OS.

Jeremy (or anyone else inside the Company), do you know if this is
deliberate? Something that could be relied on? (probably not)-:

I mean, sure, it doesn’t hurt to zero data three or four times before
the first real assignment statement. But if something is zeroed once,
that should really be enough.

– P.

On 14-Dec-2006, at 14:37, Jeremy Bernstein wrote:

> OK, you are not zeroing out the t_pxobject, as I thought when I
> first saw it, but the rest of the object, before assigning values
> to it. This can’t do any harm, but it shouldn’t really be
> necessary, assuming that you assign values to all of your struct
> members.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

#90733
Dec 20, 2006 at 2:33pm

I think that one should not rely on this. In any case, the code does
not indicate that this is being done purposely.

jb

Am 20.12.2006 um 14:53 schrieb Peter Castine:

> Jeremy (or anyone else inside the Company), do you know if this is
> deliberate? Something that could be relied on? (probably not)-:
>
> I mean, sure, it doesn’t hurt to zero data three or four times
> before the first real assignment statement. But if something is
> zeroed once, that should really be enough.

#90734
Dec 20, 2006 at 10:24pm

Jeremy Bernstein wrote:

> I think that one should not rely on this. In any case, the code does
> not indicate that this is being done purposely.

It seems to be a ‘feature’ of OS X (Xcode) that allocated memory is
automatically set to zero. At least sysmem_newptr() returns zeroed
memory on OS X and memory with garbage inside on Windows. Haven’t
checked with getbytes() but could imagine a similar behaviour.

Olaf

> Am 20.12.2006 um 14:53 schrieb Peter Castine:
>
>> Jeremy (or anyone else inside the Company), do you know if this is
>> deliberate? Something that could be relied on? (probably not)-:
>>
>> I mean, sure, it doesn’t hurt to zero data three or four times before
>> the first real assignment statement. But if something is zeroed once,
>> that should really be enough.
>
>
>

#90735
Dec 21, 2006 at 12:10am

OS X’s vm system guarantees you zero-filled pages when you first
receive a new page. Malloc may vend you non-initialized pointers if
it’s recycling memory.

The zero-filling was put in to be yet one more canary in the coal
mine, and along with the fact that we never vend you the first page
(where *(NULL) and friends exist). Unless you’ve got a struct with
members that have > 4k offsets, you’ll catch uninitialized pointer
bugs with a nifty crash instead of hours of runtime tea-leaf reading.

_Mark

On Dec 20, 2006, at 2:24 PM, Olaf Matthes wrote:

> Jeremy Bernstein wrote:
>
>> I think that one should not rely on this. In any case, the code
>> does not indicate that this is being done purposely.
>
> It seems to be a ‘feature’ of OS X (Xcode) that allocated memory is
> automatically set to zero. At least sysmem_newptr() returns zeroed
> memory on OS X and memory with garbage inside on Windows. Haven’t
> checked with getbytes() but could imagine a similar behaviour.
>
> Olaf
>
>> Am 20.12.2006 um 14:53 schrieb Peter Castine:
>>> Jeremy (or anyone else inside the Company), do you know if this
>>> is deliberate? Something that could be relied on? (probably not)-:
>>>
>>> I mean, sure, it doesn’t hurt to zero data three or four times
>>> before the first real assignment statement. But if something is
>>> zeroed once, that should really be enough.
>

#90736
Dec 21, 2006 at 10:51am

On 21-Dec-2006, at 1:10, Mark Pauley wrote:

> The zero-filling was put in to be yet one more canary in the coal
> mine, and along with the fact that we never vend you the first page
> (where *(NULL) and friends exist). Unless you’ve got a struct with
> members that have > 4k offsets, you’ll catch uninitialized pointer
> bugs with a nifty crash instead of hours of runtime tea-leaf reading.

Canaries greatly appreciated.

Now I just have to track down those Intel int div-zero errors. At
least Mac OS gives me a decent crash log, which I could never cajole
out of Blueland.

– P.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

#90737

You must be logged in to reply to this topic.