btw. A nit of mine which I've mentioned before... Since you're going to check and "fail" it would be nice to return an indication. That's a bit hard to do if everything returns void... any plans to fix that?
That deosn't mean everything has to check for failure/non-failure, but it at least should be possible, prevented by the API. thanks, Mike On 11/02/2010 02:31 PM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 31 Oct 2010 12:55:15 +0900 Daniel Juyung Seo<juyung....@samsung.com> > said: > > encouragement: good idea. indeed it hadn't been done because only until > recently did items of an obj have any form of magic numbers/checking. it > should > be done. it just had no infra before > > badness: i see you are checking... but your checks make some pretty big > assumptions. they are going to be more likely to fail than catch an error and > save the programmer from a crash. just think about it for a bit. > > normally the type checks are fairly conservative. they do depend on the > pointer > pointing to "accessible memory". but that is all they depend on. they check > the > first 4 bytes to see that it is an evas object at all (well evas does that) so > as long as what you point to has its first 4 bytes accessible, the checks can > gracefully fail (otherwise they will catch the error at some stage). so if it > meets the magic number requirements (a chance of 1 in 4 billion that something > could get past this check and NOT be an evas object. fairly small chance i'd > say), then the other fields should be validly maintained, and it can follow > this trail of breadcrumbs (check object type pointer, smart data pointer and > more). each stage is a fairly solid "hard to get by without being caught" > layer. > > now have a look at your check. the first thing is good - it checks for a > common > case. NULL. (the above do check it also first before anything else as well). > but then the next step is really really really risky. you DEPEND on it > pointing > to memory that has wd pointer at the right spot and this also being valid and > pointing to an obj - then the series of safer checks begin. the 2 levels > (depending on it ptr and wd ptr content to work) is really risky. no magic > number check first for example etc. when doing checks generally you want the > check to gracefully fail and catch the error without a crash as often as > possible. if it doesn't at least if the pointer is invalid (pointing outside > of > memory space) then its trivially catchable at that 1 dereference. you have 2 > derefs on the same line so which one will cause the crash when you have gdb > attached? it's a bit harder to catch. > > (while i'm at it.. yes we COULd even filter out invalid pointers. we could add > a pointer validity check in 1 of 2 ways. 1. look at /proc/self/maps and see if > ptr is within any of the given ranges. if it isn't - its outside of memory > space, or.. we can use the kernels trapping abilities and set custom sigsegv > +sigbus handlers (save the old) when we check the magic number. which can > avoid > a segv completely in this case at runtime, but the cost is non-trivial to set > up such handlers all the time and restore them. it's going to slow down an app > a lot at runtime so it's dubious if its a good idea, even if in theory its > possible to do. we could make it enableable given an env var too - again, only > useful then if env var on and then.,. we pay the slowdown cost too) > >> Hi there, >> >> This is a very small patch for genlist parameter verification. >> Please review and apply this to upstream. >> >> Thank you. >> Daniel Juyung Seo. > > ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
