- Dillo-dev - lists.mailman3.com

Warnings in src/IO/dpi.c and lout/misc.hh

by jcid＠dillo.org

On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > Hi, > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > dpi.c: In function ?a_Dpi_bye_dpid?: > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > Can you please check whether attached patches fix the warnings? > > @all: please have a look at the dpi.c fix. It looks OK to me. I'd just: s/p1/nl/ -- Cheers Jorge.-

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > dpi.c: In function ?a_Dpi_bye_dpid?: > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false Can you please check whether attached patches fix the warnings? @all: please have a look at the dpi.c fix. Cheers, Johannes

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by newman.x＠gmail.com

Found this three warnings when compiling with gcc-4.3.2-7.i386: gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c dpi.c: In function ?Dpi_get_dpid_uds_dir?: dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result dpi.c: In function ?a_Dpi_bye_dpid?: dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false -- Regards, Michal Nowak

March 27, 2009

google login redirect

by furaisanjin＠gmail.com

2009/3/27 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Just committed a patch for this. > ?Please test. I did login and logout several times and the redirect template showed correct link. This works. Regards, furaisanijn

March 26, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > Hi all. > > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > So generated redirect template looks like > > <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> > <td bgcolor='#8899aa' width='100%'> > This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC > (sec 7.4.4) recommends explicitly to avoid it.</td></tr> > <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go > <a href=''http://www.google.com/ ... > > So dillo just navigates to the same page. This is the reason why we can't login. Just committed a patch for this. Please test. -- Cheers Jorge.-

March 26, 2009

Re: FLTK2 r6403

by corvid＠lavabit.com

Nicol?s wrote: > Hi! Well, I am making the possible to compile Dillo in OSX. But with > the version of FLTK v6700 i can't pass the ./configure. > I am using the v6671, but there are some differences between the v6403 > (recomended in the README file). If anyone has the v6403, send it me > please =). 6700 is FLTK 1.3. You don't want that. The README says 6403 or newer. fltk-2.0.x-6671 should be fine.

March 26, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> After giving a couple of read-passes to the patch, and > considering that we still have some time before April (when I'll > have time to focus on the release), we can merge this long patch > in small independent chunks. Please separate them into different > patch files. > [...] I am definitely in favour of your idea but if I recall correctly many changes depend at each other. Therefore it could become difficult splitting it into separate patches. If I have a spare minute the next few days, I will try to do it anyway but from my point of view the easiest way would be to merge the patch as-is (or at least part of it). For the next patches, I know how to do it better. > [...] For instance I'd decline this: > > - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). > > (unless there's a strong reason I've not seen). It was ported since OO method calls in C++ are superior to C functions when it comes to readability (a_Dir_init() vs Paths::init(), a_Dir_get_owd() vs Paths::getOldWorkingDir()). The reason why I renamed the file was that the functions returned a path instead of only the directory. I also moved some file name constants to paths.hh because it makes sense organizing such path-related things within one file and to use an unified prefix (in this case PREFS_RC_). Anyway, I fully understand your view on this topic as my decision to use C++ is mostly preference- and aesthetics-driven. --Tim

March 25, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> > PS: I would like to port some C files to C++ in order to achieve > > more consistency. What is your opinion on this? > > Please don't. C++ is an unfortunate compromise we had to make to > be able to use FLTK2. It has increased complexity, reduced portability > and we'd like to confine it to a minimum (in size and features). As Dillo is already using C++, porting other parts of the code will not affect the portability negatively. Moreover, it even helps us in various ways because it improves the consistency of the whole code. As long as we do not use the STL and ``advanced'' C++ techniques, there will not be any major differences between the original and the ported code. In my opinion, the biggest advantage of C++ is its OO model which could facilitate the maintainability (assumed that it is used correctly). --Tim

March 25, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by wine.dev＠web.de

On Fr, 2009-03-20 at 19:05 +0100, Andreas Kemnade wrote: > > ...$hd id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > $ hg id http://hg.dillo.org/dillo > f4d5923de127 > > Greetings > Andreas Kemnade Thanks ! Ohloh is now on track. http://www.ohloh.net/p/dillo Current Project Cost (for a rewrite from scratch): $605.304 -- By by ... Detlef

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 04:46:33PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > > > Jorge wrote: > > > > - Removed a_Prefs_freeall because it was not used anywhere. > > > > > > Should we rip out all of the *_freeall()s? > > > > Ooops! It slipped. > > > > The idea of those functions is to free memory there. > > They don't harm when empty. Let's keep them until something > > better springs up. > > Should we add calls to them like in dillo1 and get them working, then? Yes, that'd be good. Note that those functions are called at exit time. They were added long ago to help check for memory leaks. BTW, it'd be good to have some memory usage data for dillo-2.1. Something that can be put in a web page: e.g. a table with some explanations, on how dillo-2.1 compares with dillo-0.8.6 and with a big browser. IIRC sometime ago we made tests with a 13MB page, and the notion of dillo2 having near half the memory footprint of dillo1 came from there. We need to show some numbers and how we got them. Note: I remmeber having an awful memory footprint on 64bit Ubuntu. It didn't happen with 32bit. What's the current status, I don't know. -- Cheers Jorge.-

March 25, 2009