- Dillo-dev - lists.mailman3.com

reduce warnings with gcc-4.3 [PATCH]

by corvid＠lavabit.com

Thomas wrote: > Then at last, there's an unresolved warning: > > dillo2-cvs/dw$ LANG=C make textblock.o > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -march=pentium-m -O3 -Wall -W -Wno-unused-parameter -MT textblock.o -MD -MP -MF .deps/textblock.Tpo -c -o textblock.o textblock.cc > ../lout/misc.hh: In member function 'void dw::Textblock::addLine(int, bool)': > ../lout/misc.hh:161: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > mv -f .deps/textblock.Tpo .deps/textblock.Po > > It's about this assert: > > inline T* getRef (int i) { > if (BOUND_CHECKING) > assert (i >= 0 && i < this->num); > return array + i; > } > > Ideas to please gcc with this assert? I am not sure what to think of this. I was hoping that someone who knows about these things would reply, but no such luck. Does it matter if you put the argument into a variable before calling getRef()? I don't really see what would be special about one particular instance of something->getRef(something->size() - n) when it encountered others earlier without protest, why it would (seemingly) remember that it was given (this->num - n) this one time...

Oct. 29, 2008

Hello!

by corvid＠lavabit.com

> and maybe find-as-you-type searching. You can get most of find-as-you-type for (nearly) free by taking the ReturnKey test out of Findbar::search_cb2() and changing the when() in Findbar::Findbar to something like WHEN_CHANGED. I seem to recall that there are times when this alone doesn't do quite what you might want, but I don't remember the details.

Oct. 29, 2008

dillo 2.0 on NetBSD/SPARC

by jcid＠dillo.org

Hi, FYI > Hi, > > here is a short success report: > I have compiled and tested dillo 2.0 on a Sun Ultra 1 machine with SPARC > V9 CPU running NetBSD 4.0.1 and it works (including SSL support). > > > Best regards, > > Michael Baeuerle -- Cheers Jorge.-

Oct. 28, 2008

[michael.baeuerle@stz-e.de: dillo 2.0 on NetBSD/SPARC]

by jcid＠dillo.org

Hi, FYI. -- Cheers Jorge.-

Oct. 28, 2008

patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

Oct. 28, 2008

rebased patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

Oct. 28, 2008

patch: print numeric addresses instead of pointer

by jcid＠dillo.org

On Tue, Oct 28, 2008 at 02:32:48PM +0100, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Justus Winter wrote: > > Jorge Arellano Cid wrote: > >> Not yet committed, mainly because the feature freeze for release. > >> (although the small fix went in). > > > >>> The attached patch fixes this and > >>> also adds the function > >>> > >>> void a_DilloHost_to_String(DilloHost *host, char *dst, size_t size) > >> If you finally get to a complete fix, please name exported functions > >> in dns.c with the "a_Dns_" prefix. > >> e.g. a_Dns_host_to_string > > Sure thing. Updated patch is attached. > *bump* > > > While tracking my ipv6 related problems through dillos source files I > > noticed *a lot* of ENABLE_IPV6 #ifdefs... Is this necessary for > > portability or do you want to be able to strip ipv6 support from certain > > builds? > > > > If portability at compile time is not the issue I would vote for the > > removal of those #ifdefs, if there's worry about the executables size, > > let's see: > > > > $ wc --bytes with{,out}/dillo2/src/dillo-fltk > > 3311349 with/dillo2/src/dillo-fltk > > 3309974 without/dillo2/src/dillo-fltk > > > > Well, IPv6 costs 1375 bytes on my system, I don't see any problem here, > > but I think this could be reduced. Many of those ipv6 related #ifdefs > > duplicate quite a lot of code. One tiny little cleanup patch is attached > > (please note that it depends on the a_Dns_DilloHost_to_String function). > Any thoughts on this one? Good you reminded me... IIRC the ENABLE_IPV6 stuff was because resolving was slower for IPV4 with the IPV6 code. I don't know whether this is still the case. Maybe portability is also an issue. Please send me two patches. One with a_Dns_dillohost_to_string() and another removing the ifdefs. If we get no comments on this thread, a commit experiment may take place. -- Cheers Jorge.-

Oct. 28, 2008

patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justus Winter wrote: > Jorge Arellano Cid wrote: >> Not yet committed, mainly because the feature freeze for release. >> (although the small fix went in). > >>> The attached patch fixes this and >>> also adds the function >>> >>> void a_DilloHost_to_String(DilloHost *host, char *dst, size_t size) >> If you finally get to a complete fix, please name exported functions >> in dns.c with the "a_Dns_" prefix. >> e.g. a_Dns_host_to_string > Sure thing. Updated patch is attached. *bump* > While tracking my ipv6 related problems through dillos source files I > noticed *a lot* of ENABLE_IPV6 #ifdefs... Is this necessary for > portability or do you want to be able to strip ipv6 support from certain > builds? > > If portability at compile time is not the issue I would vote for the > removal of those #ifdefs, if there's worry about the executables size, > let's see: > > $ wc --bytes with{,out}/dillo2/src/dillo-fltk > 3311349 with/dillo2/src/dillo-fltk > 3309974 without/dillo2/src/dillo-fltk > > Well, IPv6 costs 1375 bytes on my system, I don't see any problem here, > but I think this could be reduced. Many of those ipv6 related #ifdefs > duplicate quite a lot of code. One tiny little cleanup patch is attached > (please note that it depends on the a_Dns_DilloHost_to_String function). Any thoughts on this one? Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkHFIAACgkQoPmwNWhsaZbaUQCfegvuOhWQgZw1Fgbv1WUklIRs j58AoKUT8xSrbIUR6gLLHfnGNQQ1km/0 =JjH6 -----END PGP SIGNATURE-----

Oct. 28, 2008

[patch]: small update to the dpidrc build

by jcid＠dillo.org

On Mon, Oct 27, 2008 at 04:30:08PM +0000, Jeremy Henty wrote: > > I just noticed that the automake example that I based my last patch on > was careful to include the makefile as a dependency in the custom > build rule, so here's a mini-patch to do that. Committed. -- Cheers Jorge.-

Oct. 28, 2008

[patch]: small update to the dpidrc build

by onepoint＠starurchin.org

I just noticed that the automake example that I based my last patch on was careful to include the makefile as a dependency in the custom build rule, so here's a mini-patch to do that. Jeremy Henty

Oct. 27, 2008