[Cs-dev] vectorial.c compilation issue
Date | 2005-04-10 22:36 |
From | Anthony Kozar |
Subject | [Cs-dev] vectorial.c compilation issue |
I wanted to send a note about a problem I encountered when compiling vectorial.c from Cs4 CVS because I am not sure that I resolved it correctly. This is more of a C issue than a Csound one I suppose, but I am in slightly unfamiliar territory here. Basically, the following code would not compile for me with CodeWarrior because of the pointer arithmetic in the last two statements below. typedef struct { OPDS h; MYFLT *ifnOut, *ifnIn, *ifnDel, *ielements, *imaxd, *istod; AUXCH aux; MYFLT **buf, *outvec, *invec, *dlyvec; long *left, maxd; int elements; } VECDEL; void vecdly_set(VECDEL *p) { FUNC *ftp; int elements = (p->elements = (int) *p->ielements), j; [....] if (p->aux.auxp == NULL || (int)(elements * sizeof(MYFLT *) + n * elements * sizeof(MYFLT) + elements * sizeof(long)) > p->aux.size) { auxalloc(elements * sizeof(MYFLT *) + n * elements * sizeof(MYFLT) + elements * sizeof(long), &p->aux); p->buf= (MYFLT **) p->aux.auxp; for (j = 0; j < elements; j++) { p->buf[j] = (MYFLT *) (p->aux.auxp + sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * j); } p->left= (long *) (p->aux.auxp +sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * elements); } p->aux.auxp is of type void* and the compiler (rightly, I think) complains that adding an integer to a void* is illegal (since it is impossible to know the size of what it points to). I was able to get it to compile by adding casts to (MYFLT **), like this: p->buf[j] = (MYFLT *) ((MYFLT **)p->aux.auxp + sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * j); p->left= (long *) ((MYFLT **)p->aux.auxp +sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * elements); But the more that I think about it, the more that I think (MYFLT **) is wrong and it should probably be (char*). (Adding one to a MYFLT** pointer moves 4 bytes -- the size of a pointer -- and adding one to a char* pointer should move one byte, right?) So my question is, what is the correct way to fix this problem so that the code works correctly?? Thanks very much for the help. And sorry to be asking a language issue here. Anthony Kozar anthonykozar@sbcglobal.net http://akozar.spymac.net/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-10 23:09 |
From | Istvan Varga |
Subject | Re: [Cs-dev] vectorial.c compilation issue |
Anthony Kozar wrote: > But the more that I think about it, the more that I think (MYFLT **) is > wrong and it should probably be (char*). (Adding one to a MYFLT** pointer > moves 4 bytes -- the size of a pointer -- and adding one to a char* pointer > should move one byte, right?) > > So my question is, what is the correct way to fix this problem so that the > code works correctly?? If a compiler allows adding to a void* pointer, then it usually assumes that sizeof(void)==1, so the cast to char* should work. However, the code is wrong for another reason as well: the resulting MYFLT* and long* pointers may not be correctly aligned on 64 bit machines with sizeof(MYFLT)==4, and n*j or n*elements being odd: p->buf[j] = (MYFLT *) (p->aux.auxp + sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * j); p->left= (long *) (p->aux.auxp +sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * elements); By the way, in old versions of Csound (on which CsoundAV is based), AUXCH.auxp used to be char* and not void*, and this may be the source of the problem, but as mentioned above there are also alignment issues on 64 bit platforms (on which CsoundAV was obviously not intended to be run). ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 01:36 |
From | Anthony Kozar |
Subject | Re: [Cs-dev] vectorial.c compilation issue |
Thanks very much for the explanation, Istvan! I will go with the (char*) cast for now and think about the alignment issue for the future. (Perhaps the Cs5 version of vectorial.c can deal with this, but I am not sure that worrying about it for Cs4 will matter ...). I imagine the alignment issue could be solved with something like this though (done before calling auxalloc): if ( n%2 ) ++n; Anthony Kozar anthonykozar@sbcglobal.net http://akozar.spymac.net/ On 4/10/05 6:09 PM, Istvan Varga |
Date | 2005-04-11 09:11 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] vectorial.c compilation issue |
From the looks of it, casting to char* is probably what you want, as you are adding bytes to p->aux.auxp, instead of items. I suppose if the latter was the case, the original would read like this: p->buf[j] = (MYFLT *) (p->aux.auxp + elements + n * j); In fact, in CS.h, we see that typedef struct auxch { struct auxch * nxtchp; long size; void *auxp, *endp; /* was char* */ } AUXCH; at one point *auxp was a pointer to char*. I suppose vectorial.c is using an old definition of AUXCH Victor At 22:36 10/04/2005, you wrote: >I wanted to send a note about a problem I encountered when compiling >vectorial.c from Cs4 CVS because I am not sure that I resolved it correctly. >This is more of a C issue than a Csound one I suppose, but I am in slightly >unfamiliar territory here. > >Basically, the following code would not compile for me with CodeWarrior >because of the pointer arithmetic in the last two statements below. > >typedef struct { > OPDS h; > MYFLT *ifnOut, *ifnIn, *ifnDel, *ielements, *imaxd, *istod; > AUXCH aux; > MYFLT **buf, *outvec, *invec, *dlyvec; > long *left, maxd; > int elements; >} VECDEL; > >void vecdly_set(VECDEL *p) >{ > FUNC *ftp; > int elements = (p->elements = (int) *p->ielements), j; >[....] > > if (p->aux.auxp == NULL || > (int)(elements * sizeof(MYFLT *) > + n * elements * sizeof(MYFLT) > + elements * sizeof(long)) > p->aux.size) { > auxalloc(elements * sizeof(MYFLT *) > + n * elements * sizeof(MYFLT) > + elements * sizeof(long), > &p->aux); > p->buf= (MYFLT **) p->aux.auxp; > for (j = 0; j < elements; j++) { > p->buf[j] = (MYFLT *) (p->aux.auxp + sizeof(MYFLT *)* elements > +sizeof(MYFLT ) * n * j); > } > p->left= (long *) (p->aux.auxp +sizeof(MYFLT *)* elements > +sizeof(MYFLT ) * n * elements); > } > > >p->aux.auxp is of type void* and the compiler (rightly, I think) complains >that adding an integer to a void* is illegal (since it is impossible to know >the size of what it points to). I was able to get it to compile by adding >casts to (MYFLT **), like this: > >p->buf[j] = (MYFLT *) ((MYFLT **)p->aux.auxp + sizeof(MYFLT *)* elements > +sizeof(MYFLT ) * n * j); > >p->left= (long *) ((MYFLT **)p->aux.auxp +sizeof(MYFLT *)* elements > +sizeof(MYFLT ) * n * elements); > >But the more that I think about it, the more that I think (MYFLT **) is >wrong and it should probably be (char*). (Adding one to a MYFLT** pointer >moves 4 bytes -- the size of a pointer -- and adding one to a char* pointer >should move one byte, right?) > >So my question is, what is the correct way to fix this problem so that the >code works correctly?? > >Thanks very much for the help. And sorry to be asking a language issue >here. > >Anthony Kozar >anthonykozar@sbcglobal.net >http://akozar.spymac.net/ > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Csound-devel mailing list >Csound-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/csound-devel Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 09:51 |
From | Victor Lazzarini |
Subject | [Cs-dev] snapshot update |
Could anyone update the linux snapshot at the sourceforge CVS (jpff?)? Thanks a lot, Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 10:43 |
From | jpff@codemist.co.uk |
Subject | Re: [Cs-dev] snapshot update |
I had been neglecting that. Do you just want the binary or the tar as well? ==John ffitch ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 10:50 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] snapshot update |
Just the tarball sources. Thanks a lot! Victor At 10:43 11/04/2005, you wrote: >I had been neglecting that. Do you just want the binary or the tar as well? >==John ffitch > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Csound-devel mailing list >Csound-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/csound-devel Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 12:00 |
From | jpff@codemist.co.uk |
Subject | Re: [Cs-dev] vectorial.c compilation issue |
p->buf[j] = (MYFLT *) ((MYFLT **)p->aux.auxp + sizeof(MYFLT *)* elements +sizeof(MYFLT ) * n * j); Surely that should be p->buf[j] = (MYFLT *)p->aux.auxp + elements + n*j; or is the data structure over odd? Have a FOO** and not following an indirection and then casting to a FOO* is extremely contorted. ==John ffitch ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 12:35 |
From | Istvan Varga |
Subject | Re: [Cs-dev] snapshot update |
Victor Lazzarini wrote: > Just the tarball sources. Thanks a lot! But if you only need the sources, you can always get that from CVS. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 14:02 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] snapshot update |
I can't do CVS at the moment. Victor At 12:35 11/04/2005, you wrote: >Victor Lazzarini wrote: > >>Just the tarball sources. Thanks a lot! > >But if you only need the sources, you can always get that from CVS. > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Csound-devel mailing list >Csound-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/csound-devel Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2005-04-11 18:10 |
From | Anthony Kozar |
Subject | Re: [Cs-dev] vectorial.c compilation issue |
I think it's the way it is because it is trying to partition space from auxalloc() into several different arrays, not all of the same type. I originally added the cast (MYFLT **) because of this line in the code: p->buf= (MYFLT **) p->aux.auxp; Then later I began to think that this was wrong. Sorry for any confusion :) Anthony On 4/11/05 7:00 AM, jpff@codemist.co.uk |