<div class="markdown_content"><hr />
<p><strong> <a class="alink" href="http://sourceforge.net/p/pure-data/bugs/1145/">[bugs:#1145]</a> inconsitent type of argc in A_GIMME-callback</strong></p>
<p><strong>Status:</strong> open<br />
<strong>Group:</strong> v0.45<br />
<strong>Labels:</strong> API devel <br />
<strong>Created:</strong> Mon Jun 02, 2014 10:11 AM UTC by IOhannes m zmölnig<br />
<strong>Last Updated:</strong> Mon Jun 02, 2014 10:11 AM UTC<br />
<strong>Owner:</strong> Miller Puckette</p>
<p>recently, i received a bug-report for the "puredata" Debian-package,<br />
that warned of conflicting declarations of the glist_scalar() function.</p>
<p>the problem seems to be, that glist_scalar() uses "int argc" for it's<br />
A_GIMME argument in the declaration in g_canvas.c, but uses "t_int<br />
argc" in the function definition in g_scalar.c.<br />
now "t_int" is defined as a "pointer-sized integer", which is a "long<br />
int" on amd64, thus incompatible with the 32bit "int".</p>
<p>it is often tempting to use "t_int" whenever possible, as it is the<br />
Pd-native integer type.<br />
unfortunately this can (and will) break binary compatibility in some<br />
cases.</p>
<p>i think it should be <em>well documented</em> which types to use.<br />
e.g. the only way to find out how to use A_GIMME is reading the source<br />
code (where we have at least 4 occurences that use "t_int"<br />
(glist_scalar(), curve_new(), plot_new() and drawnumber_new()) and a<br />
lot more (>200) uses of "int".</p>
<p>also t_listmethod and t_anymethod in m_imp.h seem to suggest that<br />
"int" is the correct type (though "m_imp.h" was historically<br />
considered a "private" header, not meant for documentation).</p>
<p>i think it's necessary to fix all uses of "t_int argc" to "int argc".</p>
<p>additionally i think it would be good to:<br />
- clearly document the function-signature for (A_GIMME) callbacks (and<br />
while doing so, move the various callback-typedefs from m_imp.h to m_pd.h)</p>
<ul>
<li>split the generic "t_int" type into multiple names, that suggest<br />
their usage.<br />
afaict, the original use of "t_int" is for the dsp process function<br />
(t_perfroutine) , though the name does not suggest anything like this.<br />
probably we should move to a new (probably even more pointer-like) type<br />
 typedef t_perfarg void*;<br />
and replace all other uses of t_int (e.g. the return value of<br />
"atom_getint()" or the struct-member "t_resample.upsample") by other<br />
types, e.g. "int",<br />
for compatibility reasons, we might need to keep the two (or more)<br />
types the same size, but they should be separated on a semantic level.</li>
</ul>
<p>i'm attaching a patch that changes the use of <code>t_int</code> to <code>int</code> in A_GIMME callbacks.</p>
<hr />
<p>Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to <a href="https://sourceforge.net/p/pure-data/bugs/">https://sourceforge.net/p/pure-data/bugs/</a></p>
<p>To unsubscribe from further messages, a project admin can change settings at <a href="https://sourceforge.net/p/pure-data/admin/bugs/options.">https://sourceforge.net/p/pure-data/admin/bugs/options.</a>  Or, if this is a mailing list, you can unsubscribe from the mailing list.</p></div>