- Dillo-dev - lists.mailman3.com

cppcheck on Dillo source

by sgeerken＠dillo.org

> > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. > > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I've looked at this, and this is rather Johannes' code. I'm not sure whether negative may cause troubles. Sebastian

July 12, 2016

cppcheck on Dillo source

by nick＠linicks.net

On Tue, 12 Jul 2016 15:02:31 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi Nick, > > On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck > > on Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and > > attached it as a plain text file. > > Thanks for the report. I personally didn't know of cppcheck. I have used it in the past - a few years ago, but as I say I was bored so found something to do... > We have used several code cleanup tools in the past and we usually > honour them as sometimes they catch important flaws. > > A bunch of patches was just committed. You may peruse them with > "hg log -vp" for the details/explanations. Good stuff. I watch the dillo hg site anyway as I like to see (and learn) all this C++ stuff. > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I looked and looked at that, but alas, don't understand why it's wrong/right :) > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) > > Memory leak: eit3 > > Done. > > AFAICS, this is a false positive. > Patched to please cppcheck anyway. Yes, even I got that, but wasn't sure. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) > > Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) > > Uninitialized variable: X in md5.c > > Untouched: I'm not md5 savvy. Maybe corvid. Nor am I. I looked a lot at that code, and K[] whatever doesn't seem to be declared anywhere (with my little knowledge). Strange GCC doesn't squinny on that one? Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi, On Sat, Jul 09, 2016 at 03:28:25PM +0100, Nick Warne wrote: > On Sat, 9 Jul 2016 12:35:10 +0100 > Nick Warne <nick at linicks.net> wrote: > > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck on > > Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and attached > > it as a plain text file. > > > > Keep up the great work guys and thanks! > > > > Nick > > OK, updating cppcheck to 1.74, I ran it again. A new error appears, but > I don't know if it is a false positive, as I still don't really > understand C++ (but do get the logic of function calls vs void etc.: > > Checking ../../slackbuilds/dillo/hg/dillo/src/ui.cc... > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:574]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:588]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > > Now, the call is: > > make_filemenu_button(); > > to: > > Fl_Widget *UI::make_filemenu_button() > > which returns (btn) > > so is that correct? Where does (btn) go in the calling function - or > what does it do? Patch committed. It wasn't necessary anymore. Most probably it remained from a time when it was used. Now they are stored in local variables so it's safe to make the function void. -- Cheers Jorge.-

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi Nick, On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > Hi all, > > While waiting for the Tour De France to start on TV, I ran cppcheck on > Dillo source for something to do - a few errors were picked up! > > I have compacted the findings (with two comments from me)and attached it > as a plain text file. Thanks for the report. I personally didn't know of cppcheck. We have used several code cleanup tools in the past and we usually honour them as sometimes they catch important flaws. A bunch of patches was just committed. You may peruse them with "hg log -vp" for the details/explanations. > Checking ../../slackbuilds/dillo/hg/dillo/dpi/file.c... > [../../slackbuilds/dillo/hg/dillo/dpi/file.c:356]: (error) syntax error > > if S_ISDIR (finfo->mode) { > Nick-> maybe?: > if (S_ISDIR (finfo->mode)) { Done. > Checking ../../slackbuilds/dillo/hg/dillo/dpid/dpid.c... > [../../slackbuilds/dillo/hg/dillo/dpid/dpid.c:465]: (error) Resource leak: dpidrc_stream > > return -1; > Nick-> maybe?: > return (-1); Done. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer Sebastian to double check it. Not committed. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) Memory leak: eit3 Done. AFAICS, this is a false positive. Patched to please cppcheck anyway. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat Well, the code should never reach there. Not changed. @Sebastian, BTW, coincidentally I'm using something like: SortedFloatsVector *list; list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; Float *vloat = list->get (getFloatIndexFromSubRef (ref)); in some patches I have, which also silence cppcheck. But maybe the original construct was meant for adding more options (like absolute positioned floats), but those may end in a third floats array, so I'm not sure. Is it safe to use the above construct, or should I leave it as is? > Checking ../../slackbuilds/dillo/hg/dillo/lout/container.cc... > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:143]: (error) Common realloc mistake: 'array' nulled but not freed upon failure > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:177]: (error) Common realloc mistake: 'array' nulled but not freed upon failure Done. > Checking ../../slackbuilds/dillo/hg/dillo/lout/misc.cc... > [../../slackbuilds/dillo/hg/dillo/lout/misc.cc:172]: (error) Common realloc mistake: 'bits' nulled but not freed upon failure Done. > Truck loads of: > Checking ../../slackbuilds/dillo/hg/dillo/src/md5.c: ARCH_IS_BIG_ENDIAN... > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) Uninitialized variable: X > in md5.c Untouched: I'm not md5 savvy. Maybe corvid. -- Cheers Jorge.-

July 12, 2016

Problem related to generated content

by sgeerken＠dillo.org

At least it can be worked around by the user by switching off CSS, so this is not a blocker for a new release. Sebastian On Di, Jul 05, 2016, Sebastian Geerken wrote: > Hi! > > I've come upon an interesting problem. Consider this HTML (stripped > down from a real world example): > > <head> > <style> > .fc:after { > content: ""; > display: block; > clear: both; > } > </style> > </head> > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Firefox (and probably other browsers) renders black text "main" on > white background above white text "footer" on dark gray background. > Dillo 3.0.5 does the same, for the simple reason that it does not > support floats. Dillo 3.1-dev, however, renders black text "main" and > white text "footer" side by side on dark gray background, because > "main" is within a float. (Which is, of course, difficult to read.) > > The reason why Firefox renders this as it does: the definition within > <style> generates something like a block element before the text > containing "footer", with "clear: both" as CSS attributes; something > like: > > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="clear:both"></div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Aside from the fact that dillo has still problems with this ("footer" > is too much to the right; I'll investigate this independently), this > shows that dillo's limited capabilities regarding generated content, > together with floats, causes some unpleasing rendering errors, which > are furthermore laborious to analyse (and thus not so simple to > be ignored). Has someone a feasible idea to deal with this? > > Sebastian > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 10, 2016

cppcheck on Dillo source

by nick＠linicks.net

On Sat, 9 Jul 2016 12:35:10 +0100 Nick Warne <nick at linicks.net> wrote: > Hi all, > > While waiting for the Tour De France to start on TV, I ran cppcheck on > Dillo source for something to do - a few errors were picked up! > > I have compacted the findings (with two comments from me)and attached > it as a plain text file. > > Keep up the great work guys and thanks! > > Nick OK, updating cppcheck to 1.74, I ran it again. A new error appears, but I don't know if it is a false positive, as I still don't really understand C++ (but do get the logic of function calls vs void etc.: Checking ../../slackbuilds/dillo/hg/dillo/src/ui.cc... [../../slackbuilds/dillo/hg/dillo/src/ui.cc:574]: (error) Return value of allocation function 'make_filemenu_button' is not stored. [../../slackbuilds/dillo/hg/dillo/src/ui.cc:588]: (error) Return value of allocation function 'make_filemenu_button' is not stored. Now, the call is: make_filemenu_button(); to: Fl_Widget *UI::make_filemenu_button() which returns (btn) so is that correct? Where does (btn) go in the calling function - or what does it do? Nick (trying to learn). -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 9, 2016

cppcheck on Dillo source

by nick＠linicks.net

Hi all, While waiting for the Tour De France to start on TV, I ran cppcheck on Dillo source for something to do - a few errors were picked up! I have compacted the findings (with two comments from me)and attached it as a plain text file. Keep up the great work guys and thanks! Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 9, 2016

URL field / Loading page images / Refreshing DNS cache

by Johannes.Hofmann＠gmx.de

On Fri, Jul 08, 2016 at 01:23:55PM -0400, Jorge Arellano Cid wrote: > On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote: > > On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote: > > > On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > > > > First, a huge thanks to all the Dillo team for their efforts: I just > > > > switched from 3.0.5 to the current snapshot to try out the mbedtls > > > > changes, and I am wowed not only by this, but by all the improvements > > > > in rendering, etc. Great work! > > > > > > > > A few suggestions, all very minor, that might be added to the back of > > > > the development queue: > > > > > > > > In the current snapshot, the navigation bar has changed, and the URL > > > > field does not seem to be taking into account font_factor -- with the > > > > result that the window is smaller than the font height. You can test > > > > this by setting, e.g., font_factor=2.0 in your dillorc (most > > > > dramatically for a tiny panel with small icons). The issue seems to > > > > be with this factor not being taken into account when bh and lh are > > > > set in make_panel() in ui.cc. > > > > > > > > As far as I can see, one can use the context menu to download > > > > individual images on a page, or use the panel to toggle image > > > > loading. But if one wants not to download images in general, but to > > > > download all the images for some one page (e.g., a weather forecast > > > > page), then one has to toggle downloading of images on and then off > > > > again. Maybe a command could be added to KeysCommand_t in keys.hh, > > > > bound by default to something like Ctrl-i in keys.cc, with a > > > > corresponding call to a_Html_load_images() in handle() in ui.cc? > > > > > > > > To make the switch to the current snapshot, I had, sadly, to terminate > > > > an instance of 3.0.5 that had been running continuously for 90 days > > > > without any issues. But to get that much up time it was necessary to > > > > add a little code so that SIGUSR1 would call a_Dns_freeall() and > > > > a_Dns_init(), otherwise (unless I am missing something) Dillo will > > > > persist in using the cached lookup indefinitely and not detect when > > > > the IP address has changed. So maybe some sort of key binding could > > > > be added that would flush the cache when needed? > > > > > > good point. However I'd like to avoid another key-binding and rather > > > do the right thing automatically. > > > I could think of a general DNS entry timeout of a couple of seconds. > > > In many cases DNS responses are cached at OS-level too respecting > > > lifetime values given by the server. > > > > Firefox has an option to configure the DNS cache expiration > > (network.dnsCacheExpiration). > > Attached patch implements a similar feature for Dillo. > > Thanks for the patch Johannes. > > Under the current workload, I guess I'll look at it in a couple of days. > > BTW, different use cases are very interesting. We usually asume our > use case is generic. Dillo has thaught me several times that's not the > case. true > > I for instance, really avoid flushing the DNS cache as it is one of > the slowest parts of my web browsing experience. Sometimes the ISP DNS > server takes more time to answer than the page to load! > > I use another DNS but it's very noticeable, and the sites I usually browse > seldom change their IPs (I've even thought of caching to disk, go figure! ;) > > So I'd like to know what's the use case behind this need. There's surely > something on it (e.g. some site may want to distribute workload between > different servers by changing IP, etc). Searching for "getaddrinfo ttl" gives some interesting information about the topic. The general opinion seems to be that DNS caching should be handled by e.g. nscd(8) as the TTL value is available there and responses can be cached over process restarts of individual apps. That also seems to be the reason why getaddrinfo() doesn't give access to the TTL value (to avoid that all sorts of applications implement their own DNS caching scheme). Nevertheless I think that for the special case of web browsers some DNS caching is helpful. And e.g. Firefox does that too. Having a configuration option for the DNS cache expiration time one can have everything from no caching at all to caching forever. > > One thing I know DNS queries are abused for is for tracking users. > On the old dialup days, the DNS was very quick to answer, so I suspect > something fishy going on when it takes so much time here on broadband... > Cheers, Johannes

July 9, 2016

patches #4634 and #4635

by jcid＠dillo.org

Hi corvid, Some comments: ----------------- Patch #4635: rm IO flags, as they are never used Yes, those linger from a time when shutdown() was used for handling sockets in dillo. Not necessary now since we use read() write() close(). ------------------ Patch #4634: freeing http socket, close FD that's being connected Why did you do this? (i.e. Is there a specific bug?). Beware the FD is closed inside IO.c (OpEnd|OpAbort). If you close it in Http_socket_free(), you are opening race conditions on file descriptors, and coding outside the design. Http_socket_free() is used with the CCC chains, that's why it doesn't close the FD, IO will do it by means of CCC; avoiding race conditions. I haven't tested the code yet, but I'd be amazed if resources don't stop to load at random. For instance, Http_socket_reuse(int Skey) would be activating and reporting success on a socket that's just been closed. Please review all the related patches and be more careful before committing. PD: IIRC I used lsof to check for FD leaks long ago. -- Cheers Jorge.-

July 9, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Martin wrote: > Dillo builds just fine on mucosa, especially after I `brew install mbedtls` > > Problem is that, at start up, it reports > Trusting 0 TLS certificates. > > Any idea how I can install some? It's odd browsing about without https > these days. Did it work with 3.0.5 or the development branch before the recent change? (Wouldn't expect it to.) Johannes reported success on osx, but I don't know what's customary for getting certificates there... I presume https is "working" but forces you to click on dialogs...?

July 8, 2016