[PD] equality and void * pointers

Matt Barber brbrofsvl at gmail.com
Fri Oct 2 05:22:28 CEST 2015


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 object
was created. We never really have to worry about false positives, so I'm
not sure the random long is the same situation.

On Thu, Oct 1, 2015 at 9:54 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

> But if you trace error_object back, you'll see it gets created from an
> sscanf
> of a c string.  And that string was stored in the tcl/tk "text" widget as
> state bound
> to a <ctrl-click> 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 referred to.
> For example,
> the error_object could have been deleted by the user.
>
> That's why I was generating a random long in my contrived example.  If we
> cast garbage to void* and put it to the right of the equals sign, isn't
> libc
> technically allowed to respond by serving Pd users a listicle of the top
> 10 C
> programming references available from Amazon with free shipping?
>
> -Jonathan
>
>
>
> On Thursday, October 1, 2015 7:32 PM, Matt Barber <brbrofsvl at gmail.com>
> wrote:
>
>
> 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)
>         {
>             /* got it... now show it. */
>             glist_noselect(gl);
>             canvas_vis(glist_getcanvas(gl), 1);
>             canvas_editmode(glist_getcanvas(gl), 1.);
>             glist_select(gl, g);
>             return (1);
>         }
>         else if (g->g_pd == canvas_class)
>         {
>             if (glist_dofinderror((t_canvas *)g, error_object))
>                 return (1);
>         }
>     }
>     return (0);
> }
>
>
> this function takes a pointer to void (storing the address of an object)
> as its second argument void *error_object. It can't know what the type of
> that object is, because it's being called from somewhere else, and it could
> be any kind of Pd object. That somewhere else knows what kind of object it
> is and (more importantly) where that object's address is, and just passes
> that address in. Then t_gobj *g; traverses the canvas, and since the
> address of each object is known, each of those can be compared to the
> object address passed in until there's a match. This is kind of a way of
> getting around the usual strong typing in c; as long as we know from both
> ends of the transaction that we can get valid addresses of what we're
> interested in, there's no problem just comparing those addresses to see if
> we've found the same object.
>
>
>
> On Thu, Oct 1, 2015 at 4:45 PM, Jonathan Wilkes via Pd-list <
> pd-list at lists.iem.at> wrote:
>
> 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 same
> undefined behavior?
>
> -Jonathan
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151001/59982b9a/attachment.html>


More information about the Pd-list mailing list