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 <jancs...@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 <brbrof...@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 <jancs...@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 <brbrof...@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 <jancs...@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 <brbrof...@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@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@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list