[PD] equality and void * pointers

[Matt Barber]

​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 part of an error in the first place.

For 2) I think it depends on what you're going to do with the void
pointer(s). Your compare_pointers() function could actually be read as the
meat of a "guess my address!" roulette game. If you decided to write to
*bar in case it matched, it might be a "guess my address!" Russian roulette
game. I'm not sure what the compiler would say about that since I think
you'd have to cast *bar back to something you could write.



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

> Well, two questions I guess:
> 1) false positives-- if I deleted [float] and create [clip], can't malloc
> use the addy
> that belonged to [float]?  In that case [clip] could get associated with
> an error
> it had nothing to do with.
> 2) Is it undefined behavior to check void* garbage for equality?
> And just for the heck of it...
> 3) is there a way to create something like [readpd~] which would take
> indices
> as input and output the corresponding bytes of the running Pd instance? :)
>
> -Jonathan
>
>
>
>
>
> On Thursday, October 1, 2015 11:22 PM, Matt Barber <brbrofsvl at gmail.com>
> wrote:
>
>
> 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/20151002/3579c52a/attachment.html>