Luigi Castelli

void *myobj_new(t_symbol *s, short ac, t_atom *av)

t_myobj *x = (t_myobj *)object_alloc(myobj_class);

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

------------------------------------------------------------

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.

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

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?

------------------------------------------------------------
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


zeroing-out-the-object-struct

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 

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

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

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.

> 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?


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.

> No, this is an extremely bad idea. Don't do that.

> object_alloc initializes that object struct, so that

> properly identify it as a valid Max object, and so

> Where do you get these weird ideas? Not a single

> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:

> > Why? Is it necessary to zero out the object struct

> > 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

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...

> 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?
>
>

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.

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.

>> No, this is an extremely bad idea. Don't do that.

>> object_alloc initializes that object struct, so that

>> properly identify it as a valid Max object, and so

>> Where do you get these weird ideas? Not a single

>> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:

>>> Why? Is it necessary to zero out the object struct

>>> 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

> ------------------------------------------------------------

> 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.

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.

> 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


This kind of precaution can definitely catch tricky bugs, maybe if 

#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 

void *myobj_new(t_symbol *s, short ac, t_atom *av) {

t_myobj* x = (t_myobj *)object_alloc(myobj_class);

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 

> 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.

>>> No, this is an extremely bad idea. Don't do that.

>>> object_alloc initializes that object struct, so that

>>> properly identify it as a valid Max object, and so

>>> Where do you get these weird ideas? Not a single

>>> Am 14.12.2006 um 02:28 schrieb Luigi Castelli:

>>>> Why? Is it necessary to zero out the object struct

>>>> 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

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.

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

> 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
>


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

> (t_pbxobject)), sizeof(*obj) - sizeof(t_pbxobject) )

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

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

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

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 

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

> This kind of precaution can definitely catch tricky bugs, maybe if 

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

> void *myobj_new(t_symbol *s, short ac, t_atom *av) {

> t_myobj* x = (t_myobj *)object_alloc(myobj_class);

> 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 

>> 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.

>>>> No, this is an extremely bad idea. Don't do that.

>>>> object_alloc initializes that object struct, so that

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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.

> 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

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, 

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

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.

> 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.

I think that one should not rely on this. In any case, the code does 

not indicate that this is being done purposely.

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.

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

> 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.


> 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.

> 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, 

> 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.

> 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.
>
>
>


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 

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.

On Dec 20, 2006, at 2:24 PM, Olaf Matthes 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.

>> 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.

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.

> 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.
>


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 

Zeroing out the object struct