Hi, I'm trying to get rid of all compilation warnings for my library but I'm stuck with this one. Is there a way to get rid of this or I'll just have to live with it?
*warning: **incompatible integer to pointer conversion initializing 't_int *' (aka 'long *')*
* with an expression of type 'int' [-Wint-conversion]*
t_int*nblock = sp[0]->s_n;
This is where it lives => https://github.com/porres/pd-else/blob/master/Classes/Source/chance~.c#L72
Thanks
On 2/23/22 03:43, Alexandre Torres Porres wrote:
Hi, I'm trying to get rid of all compilation warnings for my library but I'm stuck with this one. Is there a way to get rid of this or I'll just have to live with it?
*warning: **incompatible integer to pointer conversion initializing 't_int *' (aka 'long *')*
with an expression of type 'int' [-Wint-conversion]*t_int*nblock = sp[0]->s_n;
that is just a bug in your code. it should read:
``` int nblock = sp[0]->s_n; ```
mgfdasr IOhannes
Em qua., 23 de fev. de 2022 às 06:21, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
that is just a bug in your code. it should read:
int nblock = sp[0]->s_n;
If I do that I get this similar warning
*warning: **incompatible integer to pointer conversion assigning*
* to 't_int *' (aka 'long *') from 'int' [-Wint-conversion]*
sigvec[n_sig - 1] = nblock; // block size (n)
this happens here => https://github.com/porres/pd-else/blob/master/Classes/Source/chance~.c#L79
'sigvec' is declared as t_int ** and is used in *dsp_addv(chance_perform, n_sig, (t_int *)sigvec);*
I tried everything and was able to remove the warning by matching things up at one point, I don't remember exactly what I did, but the problem is that the object would blow up Pd when DSP was on, so no good... So yeah, the solution to remove this warning doesn't seem to be trivial and is way over my head.
I'd really like to have no warnings at all as I believe this is some proof the code is robust, but that's just an assumption from someone who's not a real programmer.
This object has a variable number of signal outlets and I don't remember where I copied this structure from (maybe some object in Cyclone?). Perhaps I have to adopt a whole new strategy so if someone can point me to some other code out there as a reference I'd appreciate it.
thanks
'sigvec' is declared as t_int ** and is used in *dsp_addv(chance_perform, n_sig, (t_int *)sigvec);*
dsp_addv wants "t_int *" (= an array of t_int), not "t_int **", so sigvec must be "t_int *" as well. Consequently, variables must be cast to "t_int", not "t_int *", when assigning to the array.
I tried everything and was able to remove the warning by matching things up at one point
Don't just try to get rid of warnings by doing random things until they go away. Instead, try to understand them and see if they might point to an actual mistake in your code (as it is the case here).
---
As a side note: you don't necessarily need to use dsp_addv() for objects with variable inputs/outputs, you can just as well store the signal buffers (t_sample *) in an array (t_sample **) in your object.
Both methods are fine, it's just a matter of preference.
Christof
On 23.02.2022 15:18, Alexandre Torres Porres wrote:
Em qua., 23 de fev. de 2022 às 06:21, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
that is just a bug in your code. it should read: ``` int nblock = sp[0]->s_n; ```If I do that I get this similar warning
*warning: **incompatible integer to pointer conversion assigning*
*to 't_int *' (aka 'long *') from 'int' [-Wint-conversion]*
sigvec[n_sig - 1] = nblock; // block size (n)
this happens here => https://github.com/porres/pd-else/blob/master/Classes/Source/chance~.c#L79
'sigvec' is declared as t_int ** and is used in *dsp_addv(chance_perform, n_sig, (t_int *)sigvec);*
I tried everything and was able to remove the warning by matching things up at one point, I don't remember exactly what I did, but the problem is that the object would blow up Pd when DSP was on, so no good... So yeah, the solution to remove this warning doesn't seem to be trivial and is way over my head.
I'd really like to have no warnings at all as I believe this is some proof the code is robust, but that's just an assumption from someone who's not a real programmer.
This object has a variable number of signal outlets and I don't remember where I copied this structure from (maybe some object in Cyclone?). Perhaps I have to adopt a whole new strategy so if someone can point me to some other code out there as a reference I'd appreciate it.
thanks
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am 23. Februar 2022 15:39:03 MEZ schrieb Christof Ressi info@christofressi.com:
Don't just try to get rid of warnings by doing random things until they go away. Instead, try to understand them
+0.1
mfg.sfg.jfd IOhannes
Thanks!
Warnings: *gone*
Code: *better*
try to understand them and see if they might point to an actual mistake in
your code (as it is the case here).
This is why I wanted to get rid of all warnings, to make sure there were no mistakes. In many cases I could spot big mistakes.
Thanks again
Em qua., 23 de fev. de 2022 às 12:12, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Am 23. Februar 2022 15:39:03 MEZ schrieb Christof Ressi < info@christofressi.com>:
Don't just try to get rid of warnings by doing random things until they go away. Instead, try to understand them
+0.1
mfg.sfg.jfd IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig