March 2008 - Dillo-dev - lists.mailman3.com

dw::Table valgrind-friendliness
by Johannes.Hofmann＠gmx.de March 3, 2008

March 3, 2008

On Sun, Mar 02, 2008 at 03:45:09PM +0000, Jeremy Henty wrote: > On Sun, Mar 02, 2008 at 04:14:00PM +0100, Johannes Hofmann wrote: > > > I think your proposed fix is fine. It's just that I don't like the > > wrapper methods too much in the first place and now we need even > > more code to support it... > > I'm not particularly attached to my proposed fix, my real concern is > being valgrind clean because anything that makes valgrind harder to > use is bad news. My patch was just the simplest way I could see to > achieve that. If there's a better way to do it then that's great! > ok, here is my proposal. It reduces the additional code in table.cc a bit. Thanks to Jeremy for testing with valgrind. Johannes diff -r 4582dc80e696 dw/table.cc --- a/dw/table.cc Sun Mar 02 13:40:23 2008 +0100 +++ b/dw/table.cc Sun Mar 02 21:21:17 2008 +0100 @@ -516,8 +516,8 @@ void Table::forceCalcCellSizes () printf(" totalWidth2 = %d curCol=%d\n", totalWidth,curCol); #endif - colWidths->setSize (numCols); - cumHeight->setSize (numRows + 1); + colWidths->setSize (numCols, 0); + cumHeight->setSize (numRows + 1, 0); rowSpanCells->setSize (0); baseline->setSize (numRows); #ifdef DBG @@ -857,7 +857,7 @@ void Table::apportion2 (int totalWidth, if (!maxAutoWidth) // no LEN_AUTO cols! return; - colWidths->setSize (colExtremes->size ()); + colWidths->setSize (colExtremes->size (), 0); if (!forceTotalWidth && maxAutoWidth < availAutoWidth) { // Enough space for the maximum table, don't widen past max. diff -r 4582dc80e696 lout/misc.hh --- a/lout/misc.hh Sun Mar 02 13:40:23 2008 +0100 +++ b/lout/misc.hh Sun Mar 02 21:21:17 2008 +0100 @@ -161,6 +161,18 @@ public: inline void setSize(int newSize) { this->num = newSize; this->resize (); } /** + * \brief Set the size explicitely and initialize new values. + * + * May be necessary before called before misc::SimpleVector::set. + */ + inline void setSize (int newSize, T t) { + int oldSize = this->num; + setSize (newSize); + for (int i = oldSize; i < newSize; i++) + set (i, t); + } + + /** * \brief Return the reference of one element. * * \sa misc::SimpleVector::get

2 1

Re: patch: boundary for multipart/form-data submission with zero parts
by jcid＠dillo.org March 3, 2008

March 3, 2008

Hi, On Sun, Mar 02, 2008 at 07:05:08PM +0000, place wrote: > Looking again at rfc 2046, I notice that an empty boundary string is not legal. > > As for what to do in the body in that case, it's conceivable that a lifetime > of digging through RFCs would yield a definitive answer for a weird > corner case, but it's far from being worth the trouble... > (Firefox sends a body consisting of an ending boundary line "--[boundary]--") Committed. -- Cheers Jorge.-

1 0

patch: multipart/form-data encoding for form submission
by jcid＠dillo.org March 3, 2008

March 3, 2008

Hi, On Sun, Mar 02, 2008 at 09:20:53PM +0000, place wrote: > > For: > > > > > + // BUG: strstr stops at NULL. Cannot use for file inputs. > > > + success = !strstr(DataStr->str, boundary->str); > > > > please use memcmp(). > > How about if I make a separate patch for that at some point with > a Dstr_memmem() or something like that? OK. > > Some basic testing would be welcomed, but the main probe will > > be done by usage when committed. > > I added some comments, > changed the size of my dList_new() because the old value -- a holdover > from when I thought I'd do it differently -- could mislead the unwary, > and moved the dStr_free(boundary) down a little, > but this version should have no functional changes from the > version sent to the list yesterday. Committed. -- Cheers Jorge.-

1 0

dw::Table valgrind-friendliness
by onepoint＠starurchin.org March 2, 2008

March 2, 2008

Dillo has been neglecting its valgrind cleanliness recently and it turns out the culprit is dw::Table, which resizes its internal vectors without initialising any new values that appear. If you valgrind dillo and immediately close the splash window, valgrind reports 121 "Conditional jump or move depends on uninitialised value" errors! This patch reduces that number to 2! Regards, Jeremy Henty

3 7

Fixed a mistake in the CSS-box-model PNG image (style-box-model.png).
by jcid＠dillo.org March 2, 2008

March 2, 2008

Hi, I just committed this fix. The wrong documentation image mislead me a lot while working on the redraw problems. Now it's accurate (CSS box model in namespacedw_1_1core_1_1style.html). -- Cheers Jorge.-

1 0

a drawing segfault
by place＠gobigwest.com March 2, 2008

March 2, 2008

I was just opening file:///tmp/, which is not normally a problem... *** [unknown] Assertion failed! *** Array index out of bounds: 28 >= 28 Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 31812)] 0x40344c81 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0806e0ac in misc::assert (cond=false, format=0x8109030 "Array index out of bounds: %d >= %d") at ../lout/misc.hh:46 #6 0x0807ca1e in misc::SimpleVector<int>::get (this=0x81f1ff0, i=28) at ../lout/misc.hh:183 #7 0x0807b3d7 in dw::Table::draw (this=0x81b1128, view=0x8152d68, area=0xbffff414) at table.cc:242 #8 0x0807f708 in dw::Textblock::drawLine (this=0x8238228, line=0x8221594, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1364 #9 0x0807f827 in dw::Textblock::draw (this=0x8238228, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1500 #10 0x0809c2aa in dw::core::Layout::draw (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.cc:402 #11 0x08096b55 in dw::core::Layout::expose (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.hh:163 #12 0x08095fc0 in dw::fltk::FltkViewBase::draw (this=0x8152d68) at fltkviewbase.cc:113 #13 0x08090c4f in dw::fltk::FltkViewport::draw_area (data=0x8152d68, ---Type <return> to continue, or q <return> to quit--- cr=@0xbffff728) at fltkviewport.cc:168 #14 0x080d7167 in fltk::scrollrect (r=@0xbffff728, dx=0, dy=2526, draw_area=0x8090c28 <dw::fltk::FltkViewport::draw_area(void*, fltk::Rectangl e const&)>, data=0x8152d68) at scrollrect.cxx:115 #15 0x08090dfe in dw::fltk::FltkViewport::draw (this=0x8152d68) at fltkviewport.cc:189 #16 0x080bbc4b in fltk::Group::update_child (this=0x8140b40, w=@0x8152d6c) at Group.cxx:769 #17 0x080bc85a in fltk::Group::draw (this=0x8140b40) at Group.cxx:697 #18 0x080bbc4b in fltk::Group::update_child (this=0x81416d0, w=@0x8140b40) at Group.cxx:769 #19 0x080bc85a in fltk::Group::draw (this=0x81416d0) at Group.cxx:697 #20 0x080d3ed0 in fltk::Window::flush (this=0x81416d0) at x11/run.cxx:2559 #21 0x080d13ac in fl_window_flush (window=0x81416d0) at run.cxx:651 #22 0x080d146c in fltk::flush () at run.cxx:685 #23 0x080d6297 in fltk::wait (time_to_wait=0) at run.cxx:480 #24 0x080d62fd in fltk::run () at run.cxx:393 #25 0x0804ef03 in main (argc=1, argv=0xbffffb44) at dillo.cc:110

3 2

patch: multipart/form-data encoding for form submission
by place＠gobigwest.com March 2, 2008

March 2, 2008

Currently, dillo always submits forms using url encoding regardless of the encoding specified by the form. Wikipedia, for example, specifies multipart/form-data because the user may submit huge blocks of text in languages where url encoding will be very inefficient. - This patch always uses the same boundary, but a different one REALLY should be used for every form submission. At the least, the string should be scrambled up somehow. - It adds a URL_MultipartEnc flag. - For the Content-type header, I pull the boundary out of URL_DATA because I didn't want to clutter up the URL with a field for something not commonly used. ----------------------------------------------------------- For multipart/form-data, a submission goes like: [headers] Content-type: multipart/form-data; boundary="[boundary]" --[boundary] Content-Disposition: form-data; name="[name1]" [value1] --[boundary] Content-Disposition: form-data; name="[name2]" [value2] --[boundary] ...and eventually... Content-Disposition: form-data; name="[namen]" [valuen] --[boundary]--

2 7

What shall we do with the buggy RFC?
by onepoint＠starurchin.org March 1, 2008

March 1, 2008

Dillo is buggy because RFC2396 is buggy! An outrageous claim, I know, but hear me out! The problem appears when resolving a relative URI reference such as "?foo=bar" relative to a URI such as "http://a.b.c/e/f". Dillo resolves this to "http://a.b.c/e?foo=bar" ie. it loses the last path component. This is clearly wrong, and it breaks pages such as http://www.guardian.co.uk/business/gallery/2008/jan/18/1?picture=332092597 (trying clicking on the big picture - you won't get the next one in the gallery). Clearly Dillo should only lose the last path component of the base URI when the path of the relative is non-empty. Nevertheless, this broken behaviour *is* RFC compliant! If we study the 7 steps in "5.2. Resolving Relative References to Absolute Form" of RFC2396 we see a problem in step 6, which begins: a) All but the last segment of the base URI's path component is copied to the buffer. In other words, any characters after the last (right-most) slash character, if any, are excluded. So we are instructed to lose the last path component in all cases. Unfortunately we get to step 6 if the URI reference is "?foo=bar". Hence the breakage. Patch attached. Jeremy Henty

2 5