[PD] equality and void * pointers
Matt Barber
brbrofsvl at gmail.com
Fri Oct 2 07:05:33 CEST 2015
Most of the docs also don't expect you run a pointer out of the bounds of
an array, either, but the compiler trusts you know what you're doing.
I see what you mean in the first question. Can we make a patch to test it
dynamically?
On Fri, Oct 2, 2015 at 12:36 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> 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) click the error in the Pd window
> 8) GUI sends "pd findinstance .x1234567" to Pd
> 9) Pd assigns "1234567" to error_object
> 10) Pd compares [clip] object's "1234567" to old [float] addy "1234567"
> 11) It's a match!
> 12) [clip] is falsely accused
>
> For #2-- I guess I'm just anxious since most of the docs I've read assume
> a void* is either NULL or pointing to something that exists.
>
> -Jonathan
>
>
>
> On Friday, October 2, 2015 12:15 AM, Matt Barber <brbrofsvl at gmail.com>
> wrote:
>
>
> 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/40bc6e24/attachment.html>
More information about the Pd-list
mailing list