September 2014 - Dillo-dev - lists.mailman3.com

Dillo and Irix

by jcid＠dillo.org

On Thu, Sep 18, 2014 at 12:44:33PM -0300, Jorge Arellano Cid wrote: > On Tue, Sep 16, 2014 at 06:29:27AM +0000, eocene wrote: > > > > In the typical vsnprintf() (i.e., following the c99 standard), if you > > have space for 10 bytes and you want to write 20 bytes (including '\0'), > > you return 19, whereas irix returns 9. > > > > Some options: > > > > 1. It's possible to make irix and the standard run with a change like > > > > diff -r 5f63e28334b2 dlib/dlib.c > > --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 > > +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 > > @@ -406,11 +406,11 @@ > > va_copy(argp2, argp); > > n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > > va_end(argp2); > > - if (n > -1 && n < ds->sz - ds->len) { > > + if (n > -1 && n+1 < ds->sz - ds->len) { > > ds->len += n; /* Success! */ > > break; > > } else if (n > -1) { /* glibc >= 2.1 */ > > - n_sz = ds->len + n + 1; > > + n_sz = ds->len + n + 2; > > } else { /* old glibc */ > > n_sz = ds->sz * 2; > > } > > > > ...although it would need tweaking to waste less running time. > > > > But of course even if dillo is partly about retrocomputing, it'll be > > 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... > > > > 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought > > they were discouraged, but maybe the changes needed for all of that stuff > > at the bottom of Compatibility.html like > > > > SGI O2 running IRIX > > Tru64 (OSF1) 4.0 on Alpha > > QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) > > AIX 4.3 (with some tweaks) > > Atari-based 68k-systems running MiNT > > Microsoft Windows using Cygwin > > RISC OS > > > > ...just didn't make it back into mainline dillo1? > > > > 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. > > > > > > I lean toward giving it an ifdef. > > > Me too, it clearly is an IRIX issue and the #ifdef would make it > cristal clear (compared to a soln. using fltk's vsnprintf() for > instance). > > +1 A bit more elaboration: I'd add an my_vsnprintf() in dlibc and make dStr_vsprintfa() use it, and make it like: my_vsnprintf() { #if IRIX /* compute required length by using IRIX's rules */ #else /* use vsnprintf(), no problem */ #fi } To avoid autoconf, the IRIX test can be placed in the same function with a static int: static int IRIX = -1; if (IRIX == -1) { /* very simple snprintf() test here */ IRIX = test ? 1 : 0; } -- Cheers Jorge.-

Sept. 18, 2014

Dillo and Irix

by jcid＠dillo.org

On Tue, Sep 16, 2014 at 06:29:27AM +0000, eocene wrote: > > In the typical vsnprintf() (i.e., following the c99 standard), if you > have space for 10 bytes and you want to write 20 bytes (including '\0'), > you return 19, whereas irix returns 9. > > Some options: > > 1. It's possible to make irix and the standard run with a change like > > diff -r 5f63e28334b2 dlib/dlib.c > --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 > +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 > @@ -406,11 +406,11 @@ > va_copy(argp2, argp); > n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > va_end(argp2); > - if (n > -1 && n < ds->sz - ds->len) { > + if (n > -1 && n+1 < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > } else if (n > -1) { /* glibc >= 2.1 */ > - n_sz = ds->len + n + 1; > + n_sz = ds->len + n + 2; > } else { /* old glibc */ > n_sz = ds->sz * 2; > } > > ...although it would need tweaking to waste less running time. > > But of course even if dillo is partly about retrocomputing, it'll be > 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... > > 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought > they were discouraged, but maybe the changes needed for all of that stuff > at the bottom of Compatibility.html like > > SGI O2 running IRIX > Tru64 (OSF1) 4.0 on Alpha > QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) > AIX 4.3 (with some tweaks) > Atari-based 68k-systems running MiNT > Microsoft Windows using Cygwin > RISC OS > > ...just didn't make it back into mainline dillo1? > > 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. > > > I lean toward giving it an ifdef. Me too, it clearly is an IRIX issue and the #ifdef would make it cristal clear (compared to a soln. using fltk's vsnprintf() for instance). +1 -- Cheers Jorge.-

Sept. 18, 2014

Problems tackling a bug

by sgeerken＠dillo.org

Hi! FYI: For mysterious reasons, I was now able to reproduce this bug with "-O0" in gdb, so a fix was not so difficult anymore and is now in the main repository. Nevertheless, thanks for your help. Sebastian PS: (i) "-O1" still showed too much <optimized out>, and (ii) valgrind did not help, either.

Sept. 17, 2014

Dillo and Irix

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2014 at 05:49:26PM +0000, eocene wrote: > Johannes wrote: > > I would suggest testing for this specific (v)snprintf() behaviour in > > configure and ifdef based on the result rather than on the OS. > > I thought about that, and between > - it sounding like Irix == this behaviour > and > - relearning enough about autoconf to do anything is always somewhere > between unpleasant and painful > I felt disinclined, but I could give it some effort. > > > There might even be some builtin support for this check in autoconf > > as the issue is mentioned in [1]. > > I looked a bit yesterday and didn't get the impression that there > was anything. AX_FUNC_SNPRINTF might help. It worked on my system after I installed an autoconf-archive package. Here is some documentation: http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m… I think it will define PREFER_PORTABLE_SNPRINTF in config.h in case it detects a broken (v)snprintf().

Sept. 16, 2014

Dillo and Irix

by csoren＠isd.net

> > > > There might even be some builtin support for this check > > in autoconf as the issue is mentioned in [1]. > > > > I looked a bit yesterday and didn't get the impression > that there was anything. > There is an autoconf m4 macro for snprintf, with some IRIX specific checks, here: http://www.jhweiss.de/software/snprintf.html According to that page versions of IRIX all the way up to the present (6.5.30) don't adhere to the standard. For what it's worth this is the IRIX online manual page for snprintf(): http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fna…

Sept. 16, 2014

Browser tracking

by eocene＠gmx.com

James wrote: > If we implement configurable user-agents, will we start getting code > optimised for other people, which we can't run? There is the http_user_agent preference in dillorc. As for getting pages shaped for others, yes. If you're curious, I suppose you could check the Vary header in the HTTP response and see how often User-Agent is included there.

Sept. 16, 2014

Dillo and Irix

by eocene＠gmx.com

Johannes wrote: > I would suggest testing for this specific (v)snprintf() behaviour in > configure and ifdef based on the result rather than on the OS. I thought about that, and between - it sounding like Irix == this behaviour and - relearning enough about autoconf to do anything is always somewhere between unpleasant and painful I felt disinclined, but I could give it some effort. > There might even be some builtin support for this check in autoconf > as the issue is mentioned in [1]. I looked a bit yesterday and didn't get the impression that there was anything.

Sept. 16, 2014

Dillo and Irix

by eocene＠gmx.com

Jan wrote: > eocene wrote: > > >1. It's possible to make irix and the standard run with a change like > > dilo 3.0.4 works fine with your pach on Irix. Thank you very much > for your help! It would also be nice to deal with the other issues if possible. - You said you had to comment out a setenv, iirc? - I had to fix up src/Makefile in a small way which maybe could be avoided.

Sept. 16, 2014

Browser tracking

by james.from.wellington＠gmail.com

The browser on my not-incredibly-old ipod touch returned as unique, so people who run that configuration apparently have not found this site. Dillo currently returns one-in-~85000, with the user-agent being the lion's share of that. If we implement configurable user-agents, will we start getting code optimised for other people, which we can't run? On 9/10/14, eocene <eocene at gmx.com> wrote: > Jorge wrote: >> This site is interesting. It gives kind of a score of web browser >> trackability. [1] >> >> @corvid, I thought you'd like to give it a look (AFAIR, you have >> submitted >> some standardizing to our HTTP querying in the past). It looks like >> our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. >> >> It looks simple to provide some less unique alternatives in dillorc. > > Yes, this site was part of the impetus to work on the headers in March to > make dillo resemble firefox more closely, and add deflate decompression > and add keepalive. > > User-agent is a little misleading in that I have a current firefox > user-agent string, and panopticlick says that's one in 2701.57 browsers, > but no doubt it's rather more common among the visitors in > September 2014 specifically. > > Somewhat related, I've been working on SSL in the browser, and > https://www.ssllabs.com/ssltest/viewMyClient.html > shows some more ways for browsers to reveal what they are. > >> DISCLAIMER: this is just on little aspect of the privacy chain. >> Most probably this is moot unless you're behind a TOR ring. YMMV. > > Indeed. > >> >> [1] https://panopticlick.eff.org/ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 16, 2014

Patch: suppress duplicate Fl_Printer::class_id

by james.from.wellington＠gmail.com

Removing the stub on OSX 10.6.8 with fltk 1.3.2 does not make dillo grow. Sizes of dillo image; the first line counts shared libraries, and the second overestimates, perhaps consistently, the size of the to-run code: - with Fl_Printer stub without class_id: $ otool -L src/dillo | wc 14 92 1370 $ ls -l src/dillo -rwxr-xr-x 1 ... staff 2407760 15 Sep 21:21 src/dillo - without Fl_Printer stub: $ otool -L src/dillo | wc 14 92 1370 $ ls -l src/dillo -rwxr-xr-x 1 ... staff 2407760 17 Sep 00:05 src/dillo If it's purpose has been overtaken by events, and it increases the brittleness of the code, then I would be happy for it to be removed. On 9/16/14, eocene <eocene at gmx.com> wrote: > James wrote: >> Building commit 317f010 (two days ago) of dillo, I got a duplicate >> symbol on OSX 10.6.8 with gcc 4.2.1. Here is the diff that suppresses >> it. >> >> ---------------- >> $ hg diff >> diff -r c09473fb7311 dw/fltkplatform.cc >> --- a/dw/fltkplatform.cc Sat Sep 13 09:46:28 2014 +0000 >> +++ b/dw/fltkplatform.cc Sat Sep 13 23:49:26 2014 +1200 >> @@ -37,10 +37,10 @@ >> * any need for currently. This stub prevents that. */ >> class FL_EXPORT Fl_Printer : public Fl_Paged_Device { >> public: >> - static const char *class_id; >> +// static const char *class_id; >> Fl_Printer(void) {}; >> }; >> -const char *Fl_Printer::class_id = "Fl_Printer"; >> +//const char *Fl_Printer::class_id = "Fl_Printer"; > > To refresh my memory of the magnitude of what printer stuff we pull in > without the stub, I commented out the stub -- and saw nothing to do with > Fl_Printer with nm. > > I thought maybe this somehow had to do with the changes that Lauri Kasanen > made to fltk last month like > http://www.fltk.org/newsgroups.php?s10767+gfltk.commit+v10781 > http://www.fltk.org/newsgroups.php?s10787+gfltk.commit+v10787 > but I see that Manolo took out the Fl_Printer::class_id check in > Fl_Text_Display in March 2012. 1.3.2 came out in...let's see... > December 2012. > > So we should probably remove the stub altogether. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 16, 2014