Mailing Lists: January 2021

Sunday, 31 January 2021

Wednesday, 27 January 2021

In message <cceb8bf558.DaveMeUK@BeagleBoard-xM>
David Higton <dave@davehigton.me.uk> wrote:

>In message <866b6af458.harriet@bazleyfamily.co.uk>
> Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>
>> Netsurf doesn't seem to support HTML of the form
>> <OL>
>> <li type="i" value=5>
>> </OL>
>> but always defaults to a sequential numerical list, whatever type/value
>> the source specifies - are we all supposed to be styling list entries
>> with CSS nowadays?
>
> I've been having a look around some parts of the source (with which I am
> nowhere even beginning to be familiar) and docs. AFAICS (which is not very
> far!) the parser is in place to pick this stuff up. There also seem to be
> tests in place to check parsing.
>
> Some experiments indicate that it isn't rendered to screen like it should
> be, though. CSS seems to work no better than HTML. Ordered lists in upper
> case Roman and lower case alpha both come out as Arabic numerals.

In the source files, take a look in
netsurf.content.handlers.html.box_construct.c around line 400. (This is
for the 3.10 source; I haven't looked to see if it's moved in the current
version.) You'll see that cases CSS_LIST_STYLE_TYPE_DECIMAL,
CSS_LIST_STYLE_TYPE_LOWER_ALPHA, CSS_LIST_STYLE_TYPE_LOWER_ROMAN,
CSS_LIST_STYLE_TYPE_UPPER_ALPHA, CSS_LIST_STYLE_TYPE_UPPER_ROMAN and
default all use the same block of code. The marker itself is generated
in the last few lines of the block.

It ought to be not too difficult to generate code to handle the alpha
and Roman-numbered cases.

David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: OL handling

In message <866b6af458.harriet@bazleyfamily.co.uk>
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

> Netsurf doesn't seem to support HTML of the form
> <OL>
> <li type="i" value=5>
> </OL>
> but always defaults to a sequential numerical list, whatever type/value
> the source specifies - are we all supposed to be styling list entries
> with CSS nowadays?

I've been having a look around some parts of the source (with which I am
nowhere even beginning to be familiar) and docs. AFAICS (which is not
very far!) the parser is in place to pick this stuff up. There also
seem to be tests in place to check parsing.

Some experments indicate that it isn't rendered to screen like it should
be, though. CSS seems to work no better than HTML. Ordered lists in
uppr case Roman and lower case alpha both come out as Arabic numerals.
I haven't yet found where in the source the list markers are generated.

Raise a bug on Mantis and see what happens.

David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: OL handling

In article <866b6af458.harriet@bazleyfamily.co.uk>,
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
> Netsurf doesn't seem to support HTML of the form
> <OL>
> <li type="i" value=5>
> </OL>
> but always defaults to a sequential numerical list, whatever type/value
> the source specifies - are we all supposed to be styling list entries
> with CSS nowadays?

You can try. ;-)

value=n doesn't seem to work at all. (Deprecated in HTML4, reintroduced
HTML5)

CSS that works
list-style-type: circle
list-style-type: square

CSS that doesn't work and reverts to 1,2,3
list-style-type: upper-alpha
list-style-type: lower-alpha
list-style-type: upper-roman
list-style-type: lower-roman

--

Tim Hill
Webmaster, www.timil.com

websites : php : RISC OS
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Monday, 25 January 2021

Re: Dragging from URL icon

>> On 25 Nov, lists@bazleyfamily.co.uk typed:

> Thanks for confirming. It's probably an unintentional loss of
> functionality and worth reporting.
> https://bugs.netsurf-browser.org/mantis/view.php?id=2799

Thanks for raising the bug report, but I see that dragging the text that
is in the URL writable icon is still not repaired in the dev versions.

Since I frequently use the facility to drag URLs onto UniControl on the
icon bar for rendering by the dark side, I have decided to revert to
NetSurf 3.10 stable. It is in any case this version that gets into apps
bundled with RISC OS, so many people may not see the bug.

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

OL handling

Netsurf doesn't seem to support HTML of the form
<OL>
<li type="i" value=5>
</OL>
but always defaults to a sequential numerical list, whatever type/value
the source specifies - are we all supposed to be styling list entries
with CSS nowadays?

--
Harriet Bazley == Loyaulte me lie ==

It is better to be deceived by a friend, than to suspect him.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Possible integer overflow when calculating hysteresis in desktop/netsurf.c

On 24/01/2021 18:09, Jonas wrote:
> Dear NetSurf developers,
>
> I would like to point out a possible integer overflow bug on systems
> where size_t is 32-bit. In netsurf/desktop/netsurf.c:170 -- multiplying
> 'disc_cache_size' (being 1 GB) with 20 gives 0, thus resulting in
> 'hysteresis' also becoming 0.

Thanks for the report! Should be fixed in:

http://source.netsurf-browser.org/netsurf.git/commit/?id=da2aa05b730560024760a25dabc2078f578efd10

Cheers,

--
Michael Drake
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Sunday, 24 January 2021

Re: Possible integer overflow when calculating hysteresis in desktop/netsurf.c

On Sun, Jan 24, 2021 at 11:03:43AM -0800, ori@eigenstate.org wrote:
> Quoth Thorsten Otto <admin@tho-otto.de>:
> > On Sonntag, 24. Januar 2021 19:09:35 CET Jonas wrote:
> > > What do you think?
> >
> > I think that a compiler that defines size_t to be 32bit on a 64bit system is
> > broken ;)
>
> It's perfectly legal -- size_t is required to hold
> the maximum allowed object size. It's not required
> to be able to span the address space, or anything
> like that.

It's legal, but that doesn't have any relation to if it is sensible, or
if this is a bug.

Plan 9 is not sensible. And this is a bug in NetSurf.

B.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: Possible integer overflow when calculating hysteresis in desktop/netsurf.c

Quoth Thorsten Otto <admin@tho-otto.de>:
> On Sonntag, 24. Januar 2021 19:09:35 CET Jonas wrote:
> > What do you think?
>
> I think that a compiler that defines size_t to be 32bit on a 64bit system is
> broken ;)
>
>

It's perfectly legal -- size_t is required to hold
the maximum allowed object size. It's not required
to be able to span the address space, or anything
like that.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: Possible integer overflow when calculating hysteresis in desktop/netsurf.c

On Sonntag, 24. Januar 2021 19:09:35 CET Jonas wrote:

> What do you think?

I think that a compiler that defines size_t to be 32bit on a 64bit system is broken ;)

Possible integer overflow when calculating hysteresis in desktop/netsurf.c

Dear Netsurf developers,

I would like to point out a possible integer overflow bug on systems where size_t is 32-bit. In netsurf/desktop/netsurf.c:170 -- multiplying 'disc_cache_size' (being 1 GB) with 20 gives 0, thus resulting in 'hysteresis' also becoming 0. We discovered this on Plan 9 (where size_t and int is 32-bit on both 32-bit and 64-bit systems) but my tests indicate the same result (hysteresis == 0) on 32-bit Linux/GTK. What do you think?

Best,

Jonas Amoson

Monday, 18 January 2021

[gccsdk] Patch to always define limit macros in stdint.h

Index: recipe/files/gcc/libunixlib/include/stdint.h
===================================================================
--- recipe/files/gcc/libunixlib/include/stdint.h (revision 7444)
+++ recipe/files/gcc/libunixlib/include/stdint.h (working copy)
@@ -84,10 +84,6 @@
typedef unsigned long int uintmax_t;
#endif

-/* The ISO C 9X standard specifies that in C++ implementations these
- macros should only be defined if explicitly requested. */
-#if !defined __cplusplus || defined __STDC_LIMIT_MACROS
-
/* Limits of integral types. */

/* Minimum of signed integral types. */
@@ -184,10 +180,6 @@
#define WINT_MIN (0)
#define WINT_MAX (4294967295U)

-#endif /* C++ && limit macros */
-
-#if !defined __cplusplus || defined __STDC_CONSTANT_MACROS
-
/* Signed. */
#define INT8_C(c) c
#define INT16_C(c) c
@@ -205,5 +197,3 @@
#define UINTMAX_C(c) c ## ULL

#endif
-
-#endif

Attached is a patch to remove the __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS checks from stdint.h. This reflects a similar change from glibc 2.18 (https://sourceware.org/bugzilla/show_bug.cgi?id=15366), and is needed for proper compliance with C11/C++11.

Regards

Cameron

Thursday, 14 January 2021

[gccsdk] Patch to improve CMake support

Attached is a patch to improve support for CMake in the autobuilder, based on the existing support for Meson.

Regards

Cameron

[gccsdk] More various GNU tools - more Rpi lock ups.

Hi,

Following on from this discussion more RPi SWP crashes have been found in
bash and coreutils.

https://www.riscosopen.org/forum/forums/11/topics/16105

coreutils does build, and for bash revisions have been committed to enable a
build.

Test versions are at https://homepages.plus.net/pittdj/gccsdk/

Should new releases be done?

--
David Pitt

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Saturday, 9 January 2021

Re: [gccsdk] Is there a file handle equivalent of __ro_socket?

On 05/01/2021 12:05, Chris Johns wrote:
> Hello
>
> Is there a way to convert from a unixlib fd to a RISC OS file handle?
> It's actually the name of file I want but I can use OS_Args to get that
> from the risc os file handle.

Not exactly no, but the code for __get_ro_socket is:

return (int)getfd (sockfd)->devicehandle->handle;

It doesn't check that it actually has a socket fd, so it seems likely
that if you gave it a file fd you would get the RISC OS file handle
back. If we were to implement a __get_ro_file, I suspect it would
probably be the exact same code. If it does work, then perhaps

#define __get_ro_file __get_ro_socket

would be useful in your code to indicate that you're expecting a file
and not a socket.

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Tuesday, 5 January 2021

[gccsdk] Is there a file handle equivalent of __ro_socket?

Hello

Is there a way to convert from a unixlib fd to a RISC OS file handle?
It's actually the name of file I want but I can use OS_Args to get that
from the risc os file handle.

Cheers

Chris

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK