Hi list,
int compare_pointers(t_pd *foo){ long bar = generate_random_long();
return (((void *)foo) == ((void *)bar));}
(I probably have unnecessary parens there...)
Is the check for equality a case of undefined behavior?
If so, doesn't glob_findinstance of s_print.c also lead to the
As I understand it, you can compare void pointers because they just store
addresses.
In g_editor.c:
static int glist_dofinderror(t_glist *gl, void *error_object)
{
t_gobj *g;
for (g = gl->gl_list; g; g = g->g_next)
{
if ((void *)g == error_object)
{
/*
But if you trace error_object back, you'll see it gets created from an sscanfof
a c string. And that string was stored in the tcl/tk "text" widget as state
boundto a proc (or in post-1980s version of Pd that I work on,
a"hyperlink").
That state can persist well past the life of the object it
Well, two questions I guess:1) false positives-- if I deleted [float] and
create [clip], can't malloc use the addythat belonged to [float]? In that case
[clip] could get associated with an errorit had nothing to do with.2) Is it
undefined behavior to check void* garbage for equality?
And just
The left side is still determined by the current state of the patch, though
-- it's only going to check objects that are still there, which any garbage
on the right won't ever match (right?). If there is a match, it's going to
be because the state on both sides of the == was updated when the
So, if you deleted [float] and created [clip], isn't it going to bash
whatever c string was associated with [float] and associate it with [clip]?
Moreover, that kind of error has to occur in an object that exists in the
current state (I think?), so the old [float] (once it's gone) could never
be
For the first question, here's what I'm thinking:1) create [boat(---[float]2)
click [boat(3) error associated with [float]. (string ".x1234567" associated
with [float] gets saved in Pd window of GUI)4) delete [float]5) create [clip]6)
somehow the OS happens to use addy "1234567" for [clip]
7)
