On Tue, 13 Dec 2005 12:47:56 -0800 David Sharp <[EMAIL PROTECTED]> writes: > On 12/13/05, Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > > Eric Sandall [2005-12-13 11:16]: > > > > while (dst < dst_end) > > > > - *dst++ = (*src++ | PIXEL_SOLID_ALPHA) & (*dst | > 0x00ffffff); > > > > + *dst = (*src | PIXEL_SOLID_ALPHA) & (*dst | 0x00ffffff); > > > > + dst++; > > > > + src++; > > > > } > > > > > > Shouldn't pre-increment (e.g. ++dst) be used instead of > post-increment > > > (e.g. dst++) as the post-increment in C, IIRC, requires the > object to > > > be copied, incremented, and then reassigned, whereas the > pre-increment > > > just increments without all the copying and reassigning. > > > > Since you cannot overload the ++ operator, and there are no > classes and > > objects in C, this doesn't apply to C at all. > > Well, a stupid compiler might save a copy before incrementing. but > even if it does, it would not copy the whole dst buffer (I guess > this > is what you would mean by "the object"), just the 32- (or 64-) bit > pointer. Any self-respecting compiler will see that the return value > of the increment is not used, and optimize it appropriately, even > with > -O0. Tilman is correct though, this applies more to C++, where the > incremented object could be a class, than to C, where you can only > increment integral and pointer types. > > The problem with the original code (which has since been removed > from > CVS for other reasons until Jose can work on it a little more) is > that > it does not take into account WHEN the increment happens.. Does it > happen before, or after the r-value is evaluated? (I believe this is > implementation-defined.) On my box, it was happening before, leaving > the dereference on the RHS to point one after the dst on the LHS, > and > caused a segfault for me when it reached over the end of the array > despite the bounds checking in the loop. A small, easy-to-miss > oversight by Jose. I was probably lucky that it segfaulted for me, > allowing me to find it, in fact. > > d# >
Thanks for the kind words, deserved or not :) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel