- Dillo-dev - lists.mailman3.com

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

March 14, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 10:35:23PM +0100, Christian Kellermann wrote: > Dear List, > > let me again thank you for your great efforts! One minor thing I > stumbled upon today's update: My System has the following iconv > signature: size_t iconv (iconv_t cd, > const char* * inbuf, size_t * inbytesleft, > char* * outbuf, size_t * outbytesleft); > > I therefore need something like the following to make dillo compile > (an work) again: > > Index: src/html.cc > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v > retrieving revision 1.48 > diff -b -u -p -r1.48 html.cc > --- src/html.cc 13 Mar 2008 14:58:44 -0000 1.48 > +++ src/html.cc 13 Mar 2008 21:43:26 -0000 > @@ -3844,7 +3844,8 @@ static Dstr *Html_encode_text(iconv_t en > int rc = 0; > Dstr *output; > const int bufsize = 128; > - char *buffer, *inPtr, *outPtr; > + const char *inPtr; > + char *buffer, *outPtr; > size_t inLeft, outRoom; > bool bad_chars = false; You will also need to patch decode.c. > > I hope this does not break other systems. Unfortunately it does. Your system conforms to the old standard: http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html Glibc conforms to the new one: http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html One way I see to overcome this in Dillo is to define an inbuf_t from autoconf, and to use it in html.cc and decode.cc. If configure.in checks for a longer program, like: #include <iconv.h> int main(void) { const char *inPtr; char *outPtr; size_t inLeft = 0, outRoom = 0; iconv_t encoder = iconv_open("ASCII", "UTF-8"); iconv(encoder, &inPtr, &inLeft, &outPtr, &outRoom); return 0; } using gcc -Werror, if it passes, #define inbuf_t const char You can try this in your system. (but first check a simple "#define inbuf_t const char" in config.h, plus the respective patch). -- Cheers Jorge.-

March 14, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

Dear List, let me again thank you for your great efforts! One minor thing I stumbled upon today's update: My System has the following iconv signature: size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft, char* * outbuf, size_t * outbytesleft); I therefore need something like the following to make dillo compile (an work) again: Index: src/html.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v retrieving revision 1.48 diff -b -u -p -r1.48 html.cc --- src/html.cc 13 Mar 2008 14:58:44 -0000 1.48 +++ src/html.cc 13 Mar 2008 21:43:26 -0000 @@ -3844,7 +3844,8 @@ static Dstr *Html_encode_text(iconv_t en int rc = 0; Dstr *output; const int bufsize = 128; - char *buffer, *inPtr, *outPtr; + const char *inPtr; + char *buffer, *outPtr; size_t inLeft, outRoom; bool bad_chars = false; I hope this does not break other systems. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 13, 2008

[patch] don't allocate tagnames on stack

by Johannes.Hofmann＠gmx.de

Hi, here is another patch that avoids some malloc/free calls. Cheers, Johannes diff --git a/src/html.cc b/src/html.cc --- a/src/html.cc +++ b/src/html.cc @@ -194,7 +194,7 @@ struct _DilloLinkImage { }; struct _DilloHtmlState { - char *tag_name; + const char *tag_name; dw::core::style::Style *style, *table_cell_style; DilloHtmlParseMode parse_mode; DilloHtmlTableMode table_mode; @@ -815,7 +815,7 @@ DilloHtml::DilloHtml(BrowserWindow *p_bw stack = new misc::SimpleVector <DilloHtmlState> (16); stack->increase(); - stack->getRef(0)->tag_name = dStrdup("none"); + stack->getRef(0)->tag_name = "none"; stack->getRef(0)->style = NULL; stack->getRef(0)->table_cell_style = NULL; stack->getRef(0)->parse_mode = DILLO_HTML_PARSE_MODE_INIT; @@ -1014,7 +1014,6 @@ void DilloHtml::closeParser(int ClientKe Html_tag_cleanup_at_close(this, stack->getRef(si)->tag_idx); } } - dFree(stack->getRef(0)->tag_name); /* "none" */ (stack->getRef(0)->style)->unref (); /* template style */ delete (stack); @@ -1596,18 +1595,14 @@ static void Html_eventually_pop_dw(Dillo */ static void Html_push_tag(DilloHtml *html, int tag_idx) { - char *tagstr; int n_items; - - /* Save the element's name (no parameters) into tagstr. */ - tagstr = dStrdup(Tags[tag_idx].name); n_items = html->stack->size (); html->stack->increase (); /* We'll copy the former stack item and just change the tag and its index * instead of copying all fields except for tag. --Jcid */ *html->stack->getRef(n_items) = *html->stack->getRef(n_items - 1); - html->stack->getRef(n_items)->tag_name = tagstr; + html->stack->getRef(n_items)->tag_name = Tags[tag_idx].name; html->stack->getRef(n_items)->tag_idx = tag_idx; /* proper memory management, may be unref'd later */ (S_TOP(html)->style)->ref (); @@ -1635,7 +1630,6 @@ static void Html_real_pop_tag(DilloHtml (S_TOP(html)->style)->unref (); if (S_TOP(html)->table_cell_style) (S_TOP(html)->table_cell_style)->unref (); - dFree(S_TOP(html)->tag_name); hand_over_break = S_TOP(html)->hand_over_break; html->stack->setSize (html->stack->size() - 1); Html_eventually_pop_dw(html, hand_over_break); @@ -5582,7 +5576,7 @@ static int Html_write_raw(DilloHtml *htm DILLO_HTML_PARSE_MODE_VERBATIM) { /* Non HTML code here, let's skip until closing tag */ do { - char *tag = S_TOP(html)->tag_name; + const char *tag = S_TOP(html)->tag_name; buf_index += strcspn(buf + buf_index, "<"); if (buf_index + (int)strlen(tag) + 3 > bufsize) { buf_index = bufsize;

March 13, 2008

Re: patch: reorder headers in query string

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 04:42:04PM +0000, place wrote: > > It'd be good to keep the suggested ordering then. > > Attached. Committed. -- Cheers Jorge.-

March 13, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by place＠gobigwest.com

Jorge wrote: > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > This is no sort of proper fix whatsoever, but I was tired > > of seeing the "would set charset" message. It's actually > > surprisingly useful for remote files, since they're generally > > still at the javascript-and-css point at the end of the first packet. > > In CVS there is a new approach that restarts parsing the whole page. > It works with local/remote files, and page title. Please test it. In the past, I've encountered pages that go <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> </head> Here's code just sticking in a flag when meta charset's been seen.

March 13, 2008

[patch] reduce malloc/free use a bit

by jcid＠dillo.org

On Wed, Mar 12, 2008 at 09:26:52PM +0100, Johannes Hofmann wrote: > Hi, > > the patch below reduces the use of malloc/free a bit. For loading > http://www.w3.org/TR/xslt for example it reduces the number of calls > to dMalloc() from 76735 to 50478 (according to gprof). > > I have removed the SPCBuf member of html, as it seems not to be > used. Please correct me if I'm wrong or it is intended to be used > for in the future. Committed. It may remain from the old way of handling whitespace... -- Cheers Jorge.-

March 13, 2008

Re: patch: reorder headers in query string

by jcid＠dillo.org

On Wed, Mar 12, 2008 at 07:49:46PM +0000, place wrote: > Jorge wrote: > > On Wed, Mar 12, 2008 at 03:51:24PM +0000, place wrote: > > > My idea of what seems like a good ordering, for what that's worth :) > > > When I watch the headers, I always wonder why I didn't put Accept-Encoding > > > next to Accept-Charset, for one thing... > > > > AFAIR headers are ordered as they appear in the RFC. > > I'm not sure whether this is relevant, please check. > > Oh! Let's see. The RFC says: > > The order in which header fields with differing field names are > received is not significant. However, it is "good practice" to send > general-header fields first, followed by request-header or response- > header fields, and ending with the entity-header fields. > > Following that, placing them in order of appearance, yields: > > POST > > Connection > > Accept-Charset > Accept-Encoding > Host > Proxy-Authorization > Referer > User-Agent > > Content-Length > Content-Type > > Cookie > > GET > > Cache-Control > Connection > Pragma > > Accept-Charset > Accept-Encoding > Host > Proxy-Authorization > Referer > User-Agent > > Cookie > > Which is pretty close to what dillo has already if you don't count the headers > that I have added, since I never realized there was any ordering. Thanks for the info. I'd be good to keep the suggested ordering then. -- Cheers Jorge.-

March 13, 2008

patch: meta charset changes decoder

by jcid＠dillo.org

Hi, On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > This is no sort of proper fix whatsoever, but I was tired > of seeing the "would set charset" message. It's actually > surprisingly useful for remote files, since they're generally > still at the javascript-and-css point at the end of the first packet. In CVS there is a new approach that restarts parsing the whole page. It works with local/remote files, and page title. Please test it. -- Cheers Jorge.-

March 13, 2008

Re: patch: reorder headers in query string

by kelson＠pobox.com

place wrote: > - There's some kind of blog thing that knows which browsers send an Accept > header. If I pretend to use one of them, I get a meaningless error page. > This is good because it saves me from wasting time looking at blogs. Probably this: http://www.bad-behavior.ioerror.us/ It's a filter written in PHP to block spambots and harvesters that pretend to be well-known user-agents. If a user-agent always sends certain headers, then a request that claims to be that UA but lacks those headers can be treated with suspicion. If a UA claims to be Opera, Gecko, Safari, IE, etc., it will check for an Accept header. One check that I find interesting is looking for invalid Windows versions. IE will always list the internal Windows version, like "Windows NT 5.1", but people programming bots will often forget this and tell it to use "Windows XP" instead. It also checks for bots that claim to be well-known search spiders. Some bots will pretend to be Googlebot, for instance, but won't come from a Google-owned IP address. Occasionally it does run into problems with personal firewalls that strip out headers. -- Kelson Vibber www.hyperborea.org

March 13, 2008